US20140149729A1 - Reset vectors for boot instructions - Google Patents

Reset vectors for boot instructions Download PDF

Info

Publication number
US20140149729A1
US20140149729A1 US14/233,310 US201114233310A US2014149729A1 US 20140149729 A1 US20140149729 A1 US 20140149729A1 US 201114233310 A US201114233310 A US 201114233310A US 2014149729 A1 US2014149729 A1 US 2014149729A1
Authority
US
United States
Prior art keywords
state
processor
secure
information
boot
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
Application number
US14/233,310
Inventor
Ted A. Hadley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Priority to US14/233,310 priority Critical patent/US20140149729A1/en
Assigned to HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. reassignment HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HADLEY, TED A
Publication of US20140149729A1 publication Critical patent/US20140149729A1/en
Assigned to HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP reassignment HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/16Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1642Handling requests for interconnection or transfer for access to memory bus based on arbitration with request queuing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/24Resetting means
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/16Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1652Handling requests for interconnection or transfer for access to memory bus based on arbitration in a multiprocessor architecture
    • G06F13/1663Access to shared memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting 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/72Protecting 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 in cryptographic circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting 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/74Protecting 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09CCIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/31719Security aspects, e.g. preventing unauthorised access during test
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2143Clearing memory, e.g. to prevent the data from being stolen
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12Details relating to cryptographic hardware or logic circuitry

Definitions

  • a computing device such as a device including a processor, may interact with secret or otherwise sensitive information during operation. As such, some computing devices may operate to protect the sensitive information. For example, a computing device may encrypt sensitive information using a security parameter, such as an encryption key, stored on the device. The computing device may also operate to protect the security parameter stored on the device.
  • a security parameter such as an encryption key
  • FIG. 1 is a block diagram of an example processor to read boot information having different formats from different reset vectors
  • FIG. 2 is a block diagram of an example computing system comprising a processor to retrieve boot information from different reset vectors;
  • FIG. 3 is a block diagram of an example computing device to read portions of independent boot information from a plurality of reset vectors
  • FIG. 4A is a block diagram of an example computing device comprising an address selector to set region selection bits based on a state value;
  • FIG. 4B is a block diagram of an example address selector to set region selection bits based on a state value
  • FIG. 5 is a flowchart of an example method for booting a computing device with different boot information based on a state value
  • FIG. 6 is a flowchart of an example method for booting a computing device with one of a plurality of sets of boot information stored in different formats based on a state value.
  • a computing device may operate to protect sensitive information using security parameters stored on the computing device.
  • some computing device processors may have multiple operating states that may each be utilized in different stages of the life cycle of the computing device. For example, when a computing device is being developed, tested, and/or initialized in a controlled environment, a processor of the computing device may be operated in a clear state in which the processor provides little or no security for information stored on or utilized by the processor. For example, instructions executed by the processor in this clear state may be stored outside the processor in a cleartext (e.g., unencrypted, uncompressed, etc.) format.
  • a cleartext e.g., unencrypted, uncompressed, etc.
  • the processor When the computing device is operated in an environment in which it is vulnerable to security threats, the processor may be operated in a secure state in which the device provides more security for information stored on and/or utilized by the processor than in the clear state. For example, instructions and other information used by the processor in the secure state may be stored outside of the processor in an encoded (e.g., encrypted) format to prevent tampering with the information to gain access to security parameters stored on the processor. Additionally, if the computing device detects a breach of the device's security, the processor may zeroize its security parameters and operate thereafter in a zeroize state in which the processor provides event reporting and diagnostic functionalities until the device is returned to the controlled environment. A computing device may store information for each of these state concurrently, but only utilize the information (e.g., execute instructions) for the current state.
  • a processor having multiple operating states may use a single reset vector pointing to common boot information used to begin the process of booting the computing device, regardless of the desired operating state.
  • This common boot information may include common boot instructions, which may determine the desired operating state for the processor and subsequently cause the processor to read and utilize information (e.g., data and/or instructions) specific to the desired operating state.
  • the common boot instructions may additionally determine the format in which the state-specific information is stored and prepare the processor to reformat (e.g., decrypt) the state-specific information, if it is stored in a format other than a default format for the processor. For example, if the common boot instructions determine that the secure state is the desired state, the common boot instructions may then prepare the processor to decrypt any further information read from external while in the secure state.
  • the common boot information to which the reset vector points cannot have multiple different formats at the same time.
  • the common boot information cannot have the cleartext format of a clear state and an encrypted format of a secure state at the same time.
  • the common boot information may be stored in a default format (e.g., cleartext, unencrypted, etc.) so that the processor may utilize the common boot information (including common boot instructions) immediately after a reset.
  • the processor may begin reformatting and using boot information for a given state after the common boot instructions have determined the operating state and prepared the processor to reformat the state-specific boot information.
  • storing common boot information in a default format for the processor may be a point of vulnerability for the security of the processor.
  • an attacker may readily modify or replace cleartext boot instructions to thereby cause the processor to enter the wrong operating state.
  • Such altered or replaced instructions may cause the processor to enter a clear state when the common boot instructions would cause the processor to enter the secure state.
  • the attacker may be able to gain unauthorized access to security parameters stored on the processor.
  • an attacker may learn how to set the state of the processor by viewing instructions, stored in cleartext, for setting the operating state of the processor.
  • examples disclosed herein include a processor providing separate reset vectors for different operating states of the processor, and providing processor logic-based selection of and reading from one of the reset vectors based on the operating state of the processor.
  • each of the reset vectors may point to a first portion of boot information for a different operating state of the processor.
  • the boot information for different operating states including a first piece of boot information accessed for each state, may be stored in different formats. For example, a reset vector for a secure state may point to encrypted boot information and a reset vector for a clear state may point to unencrypted boot information. As such, the use of vulnerable common boot information may be eliminated.
  • examples disclosed herein provide processor logic based selection of and reading from a reset vector.
  • logic of the processor may select and read from a reset vector in response to a reset before retrieving any instruction stored outside of the processor.
  • examples disclosed herein may select the reset vector pointing to appropriately formatted boot information for the desired operating state without first loading any instruction stored outside of the processor.
  • processor logic may determine an appropriate reset vector and reformatting method, if any, from an indication of the operating state stored on the processor.
  • a processor in the secure state may begin reading and reformatting encoded boot information immediately after a reset request without first reading and utilizing vulnerable common boot instructions to determine the current state and prepare the processor to appropriately reformat state-specific information.
  • all information for the secure state that is stored outside the processor may be stored in an encoded (e.g., encrypted) format, thereby making it more difficult to tamper with information (e.g., instructions) for the secure state to gain access to security parameters stored on the processor.
  • FIG. 1 is a block diagram of an example processor 110 to read boot information having different formats from different reset vectors.
  • a “processor” may be at least one integrated circuit (IC), such as at least one semiconductor-based microprocessor, including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA) configured to retrieve and execute instructions stored on a machine-readable storage medium, other electronic circuitry suitable for the retrieval and execution of such instructions, or a combination thereof.
  • IC integrated circuit
  • CPU central processing unit
  • GPU graphics processing unit
  • FPGA field-programmable gate array
  • processor 110 includes state storage 112 and a vector controller 120 .
  • storage may be any type of memory or other electronic circuitry for storing data in any suitable format.
  • state storage 112 may include at least one register of non-volatile memory.
  • State storage 112 may store a state value 181 indicating an operating state of processor 110 .
  • an “operating state” of a processor dictates, for each of a plurality of processor functionalities, whether the processor is to permit or prevent the functionality.
  • the operating states of processor 110 include at least a clear state and a secure state.
  • the operating state of processor 110 may be the clear state when state storage 112 stores a clear state value, and may be the secure state when state storage 112 stores a secure state value different than the clear state value.
  • a “clear state” of a processor may be a state in which the processor permits functionalities for the development, initialization and/or testing of the processor.
  • a processor in the clear state may permit the storing of security parameters in secure parameter storage of the processor, but permit few or no security functionalities of the processor.
  • a “secure state” of a processor may be a state in which the processor permits the use of at least some security functionalities of the processor not permitted in the clear state.
  • vector controller 120 may receive state value 181 from state storage 112 .
  • a “vector controller” is a module of a processor including logic on the processor for selecting and reading from one of a plurality of reset vectors based on a state value of the processor, in response to a reset request, without first reading information from outside of the processor.
  • the functionality of vector controller 120 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium of processor 110 , or a combination thereof. In such examples, the vector controller may provide processor logic-based selection of and reading from one of a plurality of reset vectors regardless of how the logic on the processor is implemented.
  • a “reset vector” is an address from which a processor may first read or otherwise retrieve information from a machine-readable storage medium outside of the processor after undergoing a reset.
  • to read “from” a reset vector means to read information stored at the address of the reset vector or to read information from a sequentially-addressed portion of a storage medium starting at the address of the reset vector.
  • word-addressed storage e.g., memory
  • to read information from a reset vector may be to read the word stored at the address of the reset vector.
  • to read information from a reset vector may be to read a word (e.g., 4 bytes) stored at a plurality of sequentially-addressed bytes of the storage beginning at the address of the reset vector.
  • information stored “at” a reset vector means information stored at the address of the reset vector or information stored at sequential addresses of a storage medium starting at the address of the reset vector.
  • a reset vector may be said to “point to” information stored in a storage medium at the address of the reset vector.
  • the information stored at a reset vector may be an entry address for a set of boot instructions for booting a computing device including the processor.
  • the processor may boot the computing device by executing the boot instructions starting with the instructions at the entry address stored at the reset vector.
  • an “entry address” is the address of a point of entry into a set of instructions executable by the processor (e.g., a program, etc.).
  • a “machine-readable storage medium” may be any electronic, magnetic, optical, or other physical storage to contain or store information such as executable instructions, data, and the like.
  • any machine-readable storage medium described herein may be any of Random Access Memory (RAM), flash memory, a storage drive (e.g., a hard disk), a Compact Disc Read Only Memory (CD-ROM), and the like, or a combination thereof. Further, any machine-readable storage medium described herein may be non-transitory.
  • RAM Random Access Memory
  • flash memory e.g., a flash memory
  • storage drive e.g., a hard disk
  • CD-ROM Compact Disc Read Only Memory
  • any machine-readable storage medium described herein may be non-transitory.
  • vector controller 120 may also receive a reset request 183 .
  • reset request 183 may be generated by instructions executed by processor 110 (e.g., a software generated reset). In other examples, reset request 183 may be received from outside of processor 110 .
  • vector controller 120 may read boot information from one of a plurality of reset vectors selected based on state value 181 .
  • boot information is information that may be used by a processor to boot a computing device including the processor. In some examples, the boot information may include at least one of boot instructions and boot data.
  • boot instructions area set of instructions that may be executed by a processor to boot a computing device including the processor.
  • a set of boot instructions may be the first instructions executed by the processor after a reset of the processor.
  • Boot instructions may include, for example, instructions for testing and/or configuring components and/or functionalities of the computing device.
  • the components of the computing device to be tested and/or configured may include the processor, memory, a memory management unit, cryptographic functionalities, and the like, or a combination thereof.
  • boot data is any data (e.g., addresses, etc.) that may be used by a processor of a computing device, along with boot instructions, to boot the computing device.
  • boot data may include an address at which a first instruction of a set of boot instructions is stored in a storage medium outside of the processor.
  • a reset vector may point to boot data including an entry address for a set of boot instructions, which may be the address of a first instruction of the set of boot instructions.
  • a vector controller 120 may read this boot data (e.g., the entry address for the boot instructions) from a reset vector in response to a reset request.
  • vector controller 120 may read a portion of clear boot information from a clear state reset vector, if state value 181 indicates a clear state. For example, vector controller 120 may provide, to a machine-readable storage medium storing the clear boot information, a read request 184 to read the portion of the clear boot information from the clear state reset vector. In such examples, the clear state reset vector may be the read address of read request 184 .
  • the clear boot information may include a set of clear boot instructions and clear boot data. The clear boot data may include, for example, an entry address for the clear boot instructions, and this clear boot data may be stored in the storage medium at the address of the clear reset vector.
  • the portion of the clear boot information read from the clear state reset vector by vector controller 120 may be clear boot data including the entry address for the clear boot instructions, which may be an address at which one of the clear boot instructions is stored.
  • processor 110 may boot the computing device including processor 110 by executing the clear boot instructions beginning with the instruction at the entry address read from the clear state reset vector.
  • vector controller 120 may read a portion of secure boot information from a secure state reset vector. For example, vector controller 120 may provide, to a machine-readable storage medium storing the secure boot information, a read request 186 to read the portion of the secure boot information from the secure state reset vector.
  • the secure state reset vector may be the read address of read request 186 .
  • the secure boot information may include a set of secure boot instructions and secure boot data.
  • the secure boot data may include, for example, an entry address for the secure boot instructions, and this secure boot data may be stored in the storage medium at the address of the secure reset vector.
  • the portion of the secure boot information read from the secure state reset vector by vector controller 120 may be secure boot data including the entry address for the secure boot instructions, which may be an address at which one of the secure boot instructions is stored.
  • processor 110 may boot the computing device including processor 110 by executing the secure boot instructions beginning with the instruction at the entry address read from the secure state reset vector.
  • vector controller 120 may select one of a plurality of reset vectors in response to reset request 183 by selectively altering an address of a read request generated by processor 110 .
  • vector controller 120 may include a core module of processor 110 and, in response to reset request 183 , the core module may output a read request having as the read address a default reset vector for the core module (e.g., for an interrupt handler of the core module).
  • vector controller 120 may determine that a read address on an address bus of processor 110 refers to a reset region of a machine-readable storage medium, and may selectively substitute at least one region selection bit, set based on state value 181 , for at least one bit of the address on the address bus.
  • vector controller 120 may selectively alter the address of a read request provided in response to reset request 183 to thereby read from a reset vector associated with state value 181 in response to reset request 183 .
  • vector controller 120 may select the reset vector in response to reset request 183 in other ways.
  • a core module included in vector controller 120 may receive state value 181 and select one of a plurality of state-specific reset vectors stored in the core module in response to reset request 183 .
  • the state-specific reset vectors may each be stored in non-volatile storage of the core module or hard-coded in logic of the core module.
  • the core module may, in response to reset request 183 , output a read request having a reset vector associated with state value 181 as the read address.
  • the clear boot information may have a first format, while the secure boot information has a second format different than the first format.
  • the clear boot information may be stored in a cleartext or an otherwise unencrypted format, while the secure boot information may be stored in an encrypted format.
  • information in a “cleartext” format is information that a processor receiving the information is configured to execute or otherwise operate on without first reformatting (e.g., decrypting, decoding, etc.) the instruction.
  • an instruction in a cleartext format may be an instruction that the processor may execute without reformatting
  • an address in a cleartext format may be an address from which the processor may read without first reformatting the address.
  • information in an “encrypted” format is information in a format that a processor receiving the information may execute or otherwise operate on after decrypting the instruction.
  • all information for a given state stored outside of processor 110 may have the same format.
  • all information e.g., data, instructions
  • all information that may be utilized by processor 110 in the clear state including the clear boot information and information and/or executable instructions for other clear state applications, may be stored outside the processor in the same format (e.g., the first format).
  • all information that may be utilized by processor 110 in the secure state including the secure boot information and information and/or executable instructions for other secure state applications, may be stored outside the processor in the same format (e.g., the second format).
  • vector controller 120 may include a formatting module that may determine whether to reformat information read from outside of processor 110 based on state value 181 . In such examples, when the state value 181 indicates the secure state, the formatting module may decrypt the secure boot instructions read from outside of processor 110 .
  • the first and second formats may be any two formats different from one another. In some examples, the first and second formats may both be formats other than cleartext. For example, information in the first format may be encrypted or otherwise encoded (e.g., compressed, etc.) in any manner different than the manner in which information in the second format is encrypted or otherwise encoded. In some examples, the first and second formats may be different encrypted formats. In such examples, information in the first and second formats may be encrypted differently (e.g., using different encryption formats and/or different encryption keys, etc.).
  • a processor may read boot information from different reset vectors based on an operating state of the processor in response to a reset request. By selecting a state-specific reset vector based on the operating state with logic of the processor, the processor may select an appropriate reset vector and begin reading state-specific boot information in response to a reset request before reading any other information from outside of the processor. Additionally, the processor may include a reformatting module to selectively reformat received information based on the operating state of the processor. In such examples, the processor may, in different operating states, process differently formatted instructions beginning with a very first instruction read from outside the processor after a reset. In this manner, examples described herein may eliminate the use of vulnerable, cleartext common boot instructions.
  • FIG. 2 is a block diagram of an example computing system 295 comprising a processor 110 to retrieve boot information from different reset vectors.
  • Computing system 295 includes processor 110 and a machine-readable storage medium 250 .
  • storage medium 250 includes clear boot information 252 having a first format, secure boot information 254 having a second format, and zeroize boot information 256 .
  • Clear boot information 252 may include clear boot data 253 A and clear boot instructions 253 B each having the first format
  • secure boot information 254 may include secure boot data 255 A and secure boot instructions 255 B each having the second format
  • zeroize boot information 256 may include zeroize boot data 257 A and zeroize boot instructions 257 B.
  • processor 110 includes state storage 112 and vector controller 120 , as described above in relation to FIG. 1 .
  • vector controller 120 may provide read requests 184 and 186 to a machine-readable storage medium.
  • storage medium 250 may provide, to processor 110 , information 287 stored at the address indicated by the read request.
  • vector controller 120 may provide read request 184 to storage medium 250 to read a portion of clear boot information 252 having the first format from a clear state reset vector, if state value 181 indicates the clear state.
  • the portion of clear boot information 252 read from the clear state reset vector may be clear boot data 253 A, which may include an entry address for clear boot instructions 253 B.
  • processor 110 may boot a computing device including processor 110 with clear boot instructions 253 B after reading clear boot data 253 A from the clear state reset vector. For example, after reading clear boot data 253 A from the clear state reset vector, processor 110 may begin executing clear boot instructions 253 B beginning with a clear boot instruction stored at the entry address stored at the clear state reset vector.
  • vector controller 120 may, in response to reset request 183 , provide read request 186 to storage medium 250 to read a portion of secure boot information 254 having the second format from a secure state reset vector.
  • the portion of secure boot information 252 read from the secure state reset vector may be secure boot data 255 A, which may include an entry address for secure boot instructions 255 B.
  • processor 110 may boot a computing device including processor 110 with secure boot instructions 255 B after reading secure boot data 255 A from the secure state reset vector. For example, after reading secure boot data 255 A from the secure state reset vector, processor 110 may begin executing secure boot instructions 255 B beginning with a secure boot instruction stored at the entry address stored at the secure state reset vector.
  • processor 110 may verify that secure boot information 254 has not been altered by checking at least some of secure boot information 254 against validation data, such as a digital signature, of secure boot information 254 .
  • validation data may be any type of data that may be derived from a collection of information and subsequently used to determine whether the information has been altered since generation of the validation data.
  • at least some of secure boot information 254 may be stored on processor 110 (e.g., in a cache) until processor 110 verifies that validation data derived from the stored information matches the validation data included in the secure boot information 254 .
  • the verification data may be derived using hashing, processes used for error detection (e.g., processes used to generate a checksum, a cyclic redundancy check (CRC), etc.), or the like. If the derived validation data matches the validation data of boot information 254 , the instructions may be executed, and otherwise not.
  • any state-specific information stored on storage medium 250 may include validation data for the information, and processor 110 may verify the validation data prior to utilizing some or all of the information.
  • vector controller 120 includes a core module 222 and a formatting module 225 including an encryption module 227 .
  • the functionalities of modules 222 , 225 , and 227 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.
  • core module 222 may include or implement the functionalities of a CPU core.
  • a “CPU core” is a component of a processor capable of at least executing instructions.
  • a CPU core may include at least one of an arithmetic logic unit (ALU), an interrupt handler, a fetch controller, a data write-back controller, a floating-point unit, or a combination thereof.
  • ALU arithmetic logic unit
  • core module 222 may execute or otherwise operate on information having the first format without this information first being reformatted.
  • core module 222 may execute instructions having the first format and may operate on data (e.g., addresses) having the first format.
  • the first format may be a cleartext format.
  • formatting module 225 may reformat information received by processor 110 based on state value 181 of processor 110 .
  • information read from or written to storage medium 250 by processor 110 may pass through formatting module 225 .
  • formatting module 225 may have multiple operating modes, which may be selected based on state value 181 .
  • formatting module 225 may have a bypass mode, in which formatting module 225 forwards received information without reformatting the information, and at least one formatting mode, in which formatting module 225 reformats received information.
  • formatting module 225 may have multiple different formatting modes associated with different operating states of processor 110 and different formats associated with those operating states.
  • information used by processor 110 in the clear state may be stored outside of processor 110 in the first format.
  • information 287 read from storage medium 250 when processor 110 is in the clear state (e.g., clear boot information 252 ) may have the first format.
  • information read in the clear state may be passed to core module 222 without first being reformatted.
  • formatting module 225 may operate in a bypass mode in which it outputs received information without reformatting the information, if state value 181 indicates a clear state.
  • formatting module 225 may receive information 287 and output the received information in the format in which it was received, if state value 181 indicates the clear state.
  • information used by processor 110 in the secure state may be stored outside of processor 110 in the second format.
  • information 287 read from storage medium 250 when processor 110 is in the secure state e.g., secure boot information 254
  • formatting module 225 may reformat information 287 received from storage medium 250 from the second format to the first format, if state value 181 indicates the secure state.
  • formatting module 225 may include an encryption module 227 to encrypt and decrypt information.
  • the second format may be an encrypted format for protecting the information for the secure state when stored outside of processor 110
  • the first format may be an unencrypted format, such as a cleartext format.
  • encryption module 227 may decrypt received information 287 from an encrypted second format to the unencrypted first format, if state value 181 indicates the secure state.
  • storing information used in the secure state in an encrypted format when stored outside of processor 110 may provide additional security for the secure state of processor 110 .
  • the information may be kept secret when stored outside of the processor when stored in an encrypted format. Additionally, it may be difficult to effectively replace or modify sections of code stored in an encrypted format.
  • formatting module 225 may reformat information 289 to be written to storage medium 250 from the first format to the second format (e.g., encrypt the information) before writing the information. In such examples, if the information written is subsequently read by processor 110 in the secure state, then formatting module 225 may reformat the information from the second to the first format.
  • formatting module 225 may allow all information utilized by a processor in a given mode to be stored outside of the processor in a state-specific format. For example, all information for the clear state, including the information stored at the clear state reset vector, may be stored in first format (e.g., a cleartext format), while all information for the secure state, including the information stored at the secure state reset vector, may be stored in a second format (e.g., an encrypted format). In such examples, formatting module 225 may correctly reformat (or bypass) all information read in a given operating state of the processor, beginning with information read from a state-specific reset vector, based on state value 181 . In this manner, examples disclosed herein may eliminate the use of common boot information, and instead allow state-specific boot information to be used in each operating state. Further, in some examples, the state-specific boot information for different states may have different, state-specific formats.
  • the operating states of processor 110 may include a zeroize state in addition to the clear and secure states.
  • the operating state of processor 110 may be the zeroize state when state storage 112 stores a zeroize state value, different that the clear and secure state values, as state value 181 .
  • a “zeroize state” of a processor may be a state entered by the processor after detection of a security incident and in which the processor prevents the storage of security parameters and permits diagnostic functionalities of the processor.
  • a processor in the zeroize state may permit event reporting functionalities, but permit few or no security functionalities of processor 110 .
  • vector controller 120 may provide a read request 288 to storage medium 250 to read a portion of zeroize boot information 256 from a zeroize state reset vector, if state value 181 indicates the zeroize state.
  • the portion of zeroize boot information 256 read from the zeroize state reset vector may be zeroize boot data 257 A, which may include an entry address for secure boot instructions 257 B.
  • processor 110 may boot a computing device including processor 110 with zeroize boot instructions 257 B after reading zeroize boot data 257 A from the zeroize state reset vector. For example, after reading zeroize boot data 257 A from the zeroize state reset vector, processor 110 may begin executing zeroize boot instructions 257 B beginning with a zeroize boot instruction stored at the entry address stored at the zeroize state reset vector.
  • zeroize boot information 256 may have a third format different than the first and second formats.
  • zeroize boot information 256 may be encoded, encrypted, or otherwise formatted differently than clear and secure boot information 252 and 254 .
  • clear boot information 252 is in a cleartext format
  • secure boot information 254 is encrypted
  • zeroize boot information 256 may be encrypted differently than secure boot information 254 (e.g., encrypted with a different key or by a different process), or may be compressed or otherwise encoded by a suitable process other than encryption.
  • the first, second, and third formats may be any three formats different from one another.
  • all three formats may be formats other than cleartext.
  • information in the first, second, and third formats may each be encrypted, encoded, or otherwise formatted such that the three formats are different from one another.
  • information used by processor 110 in the zeroize state may be stored outside of processor 110 in the third format.
  • information 287 read from storage medium 250 when processor 110 is in the zeroize state (e.g., zeroize boot information 256 ) may have the third format.
  • formatting module 225 may reformat information 287 received from storage medium 250 from the third format to the first format, if state value 181 indicates the zeroize state.
  • formatting module 225 may have multiple formatting modes. For example, formatting module 225 may operate in a first formatting mode to reformat information from the second to the first format, if state value 181 indicates the secure state.
  • formatting module 225 may operate in a second formatting mode to reformat information from the third to the first format, if state value 181 indicates the zeroize state.
  • zeroize boot instructions 256 may have the same format as clear boot instructions 252 (i.e., the first format). In such examples, formatting module 225 may enter a bypass mode if state value 181 indicates the zeroize state.
  • vector controller 120 may select one of the plurality of reset vectors in response to reset request 183 in any manner described above in relation to FIG. 1 . For example, vector controller 120 may select one of the plurality of reset vectors in response to reset request 183 by selectively altering an address of a read request generated by processor 110 , as described above in relation to FIG. 1 .
  • all information for a given state stored outside of processor 110 may have the same format, as described above in relation to FIG. 1 .
  • all information that may be utilized by processor 110 in the clear state may be stored outside the processor in the same format
  • all information that may be utilized by processor 110 in the secure state may be stored outside the processor in the same format.
  • all information e.g., data, instructions
  • all information may be utilized by processor 110 in the zeroize state, including the zeroize boot information and information and/or executable instructions for other zeroize state applications, may be stored outside the processor in the same format (e.g., the third format).
  • other examples may include additional and/or other states.
  • FIG. 3 is a block diagram of an example computing device 300 to read portions of independent boot information from a plurality of reset vectors.
  • a “computing device” may be a desktop or, notebook computer, a tablet computer, a computer networking device (e.g., a hardware security module), a server, or any other device or equipment (e.g., an automated teller machine (ATM), etc.) including a processor.
  • computing device 300 may be any of the devices noted above.
  • Computing device 300 may include a processor 310 and a machine-readable storage medium 350 .
  • Processor 310 may include state storage 112 and a vector controller 120 , as described above in relation to FIGS. 1 and 2 . In the example of FIG.
  • processor 310 also includes a storage control module 332 , secure parameter storage 334 , and a security control module 340 .
  • Security control module 340 may include an incident monitor module 342 , a record storage module 344 , a zeroize module 346 , and an indication module 348 .
  • the functionalities of modules 332 , 340 , 342 , 344 , 346 , and 348 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.
  • storage medium 350 may include clear boot information 252 and secure boot information 254 , as described above in relation to FIG. 2 .
  • clear boot information 252 may have a first format and secure boot information 254 may have a second format different than the first format, as described above in relation to FIG. 2 .
  • storage medium may further include zeroize boot information 356 , which may be similar to zeroize boot information 256 , except that it may have the first format rather than a third format, as described above in relation to FIG. 2 .
  • zeroize boot data 357 A and zeroize boot instructions 357 B may be the same as zeroize boot data 257 A and zeroize boot instructions 257 B, respectively, except stored in different formats.
  • state storage 112 may store state value 181 indicating an operating state of processor 310 , as described above in relation to FIGS. 1 and 2 .
  • the operating states of processor 310 may include at least the clear state, the secure state, and the zeroize state.
  • each of the operating states of processor 310 may cause processor 310 to operate in a manner appropriate for different stages of the life cycle of computing device 300 . For example, during development, testing, and/or initialization of computing device 300 in a controlled environment, processor 310 may be operated in the clear state in which few or no security functionalities of processor 310 are permitted.
  • processor 310 may operate in the secure state, in which processor 310 permits the operation of security functionalities not permitted in the clear state to protect information stored on or utilized by processor 310 .
  • processor 310 may zeroize at least one security parameter in secure parameter storage 334 and enter a zeroize state in response to the detection of a security incident.
  • processor 310 may permit diagnostic functionalities for investigating the security incident that caused processor 310 to enter the zeroize state and prevents the storage of security parameters in secure parameter storage 334 .
  • vector controller 120 may provide a read request 384 to storage medium 350 to read a portion of clear boot information 252 from a clear state reset vector, if state value 181 indicates the clear state.
  • the read address of read request 384 may be the clear state reset vector.
  • the portion of clear boot information 252 read from the clear state reset vector may be clear boot data 253 A, which may include an entry address for clear boot instructions 253 B.
  • processor 110 may boot computing device 300 with clear boot instructions 253 B after reading clear boot data 253 A from the clear state reset vector, as described above in relation to FIG. 2 .
  • vector controller 120 may, in response to reset request 183 , provide read request 386 to storage medium 350 to read a portion of secure boot information 254 from a secure state reset vector.
  • the read address of read request 386 may be the secure state reset vector.
  • the portion of secure boot information 252 read from the secure state reset vector may be secure boot data 255 A, which may include an entry, address for secure boot instructions 255 B.
  • processor 110 may boot computing device 300 with secure boot instructions 255 B after reading secure boot data 255 A from the secure state reset vector, as described above in relation to FIG. 2 .
  • vector controller 120 may provide a read request 388 to storage medium 250 to read a portion of zeroize boot information 356 from a zeroize state reset vector, if state value 181 indicates the zeroize state.
  • the read address of read request 388 may be the zeroize state reset vector.
  • the portion of zeroize boot information 356 read from the zeroize state reset vector may be zeroize boot data 357 A, which may include an entry address for secure boot instructions 357 B.
  • processor 310 may boot computing device 300 with zeroize boot instructions 3578 after reading zeroize boot data 357 A from the zeroize state reset vector, as described above in relation to zeroize boot instructions 356 of FIG. 2 .
  • vector controller 120 may select one of the plurality of state-specific reset vectors in response to reset request 183 in any manner described above in relation to FIG. 1 .
  • vector controller 120 may include formatting module 225 , as described above in relation to FIG. 2 .
  • formatting module 225 may reformat information 287 read from storage medium 250 , as described above in relation to FIG. 2 .
  • clear and zeroize boot information 252 and 356 may have the first format, while the secure boot information 254 may have a second format different than the first format.
  • the clear and zeroize boot information 252 and 356 may be stored in a cleartext or an otherwise unencrypted format, while secure boot information 254 may be stored in an encrypted format.
  • formatting module 225 may operate in a bypass mode if state value 181 indicates the clear or zeroize state.
  • clear boot information 252 , secure boot information 254 , and zeroize boot information 356 may each be stored in a different format on storage medium 350 .
  • all information for a given state stored outside of processor 110 may have the same format, as described above in relation to FIGS. 1 and 2 .
  • all information that may be utilized by processor 110 in the clear state may be stored in the same format
  • all information that may be utilized by processor 110 in the secure state may be stored in the same format
  • all information that may be utilized by processor 110 in the zeroize state may be stored in the same format.
  • clear boot information 252 , secure boot information 254 , and zeroize boot information 356 are independent from one another. Moreover, in such examples, clear, secure, and zeroize boot instructions 253 B, 255 B, and 357 B are independent from one another. In such examples, clear boot information 252 , secure boot information 254 , and zeroize boot information 356 each include a full set of boot data and instructions that may be used to boot computing device 300 . In some examples, each of clear boot information 252 , secure boot information 254 , and zeroize boot information 356 is sufficient for performing a cold boot of computing device 300 (i.e., to boot computing device 300 from an off state after power is applied).
  • each of clear, secure, and zeroize boot instructions 253 B, 255 B, and 357 B may include instructions for testing and/or configuring components and/or functionalities of computing device 300 , and for otherwise preparing computing device 300 to operate in accordance with a current operating state of processor 310 , as indicated by state value 181 .
  • processor 310 includes secure parameter storage 334 and a storage control module 332 .
  • secure parameter storage 334 may store at least one security parameter for processor 310 .
  • a “security parameter” is information used by a computing device for cryptography, authentication, or any other security functionality of the computing device. Some examples of security parameters may include, for example, cryptographic keys, initialization vectors, personal identification numbers (PINs), public exponents for cryptography, and the like.
  • secure parameter storage 334 is storage in which processor 310 may store security parameters for use by processor 310 .
  • storage control module 332 may control interaction with secure parameter storage 334 in accordance with the operating state of processor 310 .
  • storage control module 332 may permit processor 310 to write security parameters to secure parameter storage 334 based on state value 181 .
  • storage control module 332 may permit information, such as security parameters, to be written to secure parameter storage 334 if state value 181 indicates the clear state or the secure state.
  • processor 310 may allow a host device, external to processor 310 and computing device 300 , to write a security parameter 385 to secure parameter storage 334 .
  • storage control module 332 may prevent information, such as security parameters, from being written to secure parameter storage 334 if state value 181 indicates the zeroize state. For example, storage control module 332 may detect an operation to write to secure parameter storage 334 . If state value 181 indicates the clear or secure state, storage control module 332 may take no action to prevent the write operation. If state value 181 indicates the zeroize state, storage control module 332 may prevent the write operation by, for example, preventing a write control signal from being asserted or by causing a processor exception to prevent the write operation.
  • security control module 340 may control the response of processor 310 to a security incident based on the operating state of processor 310 .
  • security control module includes an incident monitor module 342 that may monitor processor 310 for security incidents.
  • a “security incident” is an event affecting or otherwise related to a computing device or a component thereof that may, alone or in combination with at least one other event, increase the vulnerability of information stored on the computing device.
  • a security incident may be a change in a condition or configuration of a computing device or receipt of any signal by the computing device that may, alone or in combination with at least one other change or signal, increase the vulnerability of information stored on the computing device.
  • incident monitor module 342 may monitor processor 310 and/or computing device 300 for security incidents.
  • incident monitor module 342 may detect a security incident upon determining that an actual or attempted physical tampering with or probing of processor 310 has occurred, upon determining that a signal received by processor 310 is part of an attack (e.g., is a forged signal, a replayed signal, etc.), upon receiving a signal indicating the occurrence of a security incident from another incident monitor external to processor 310 , and the like.
  • zeroize module 346 may zeroize at least one security parameter stored in secure parameter storage 334 if state value 181 indicates the secure state.
  • “zeroization” of information includes at least one of erasing and overwriting the information at least once.
  • Zeroization module 346 may erase and/or overwrite some or all of the contents of secure parameter storage 334 .
  • zeroization module 346 may overwrite each bit of the security parameters multiple times.
  • module 346 may overwrite each bit of the security parameters with a first logic value (e.g., 0), then with a second logic value (e.g., 1), and then overwrite the security parameters with a combination of logic 1's and logic 0's. Also, in some examples, module 346 may erase security parameters and then take further actions to prevent the recovery of the erased parameters, such as overwriting the erased parameters at least once, to complete the zeroization of the security parameters. In addition to zeroizing storage 334 , record storage module 344 may also store an incident record, as described above in relation to the clear state, if state value 181 indicates the secure state.
  • a first logic value e.g., 0
  • second logic value e.g. 1
  • module 346 may erase security parameters and then take further actions to prevent the recovery of the erased parameters, such as overwriting the erased parameters at least once, to complete the zeroization of the security parameters.
  • record storage module 344 may also store an incident record, as described above in relation to the clear state,
  • record storage module 344 may store an incident record in response to incident monitor module 342 detecting a security incident.
  • record storage module 344 may store the incident record in record storage on or external to processor 310 .
  • the incident record may include details of the security incident, such as the date, time, event that triggered the detection of the security incident, and any other details that may be used to diagnose, study or further determine the cause of the security incident.
  • security control module 340 may prevent zeroize module 346 from zeroizing of any parameter of secure parameter storage 334 if state value 181 indicates the clear state.
  • processor 310 may be tested in the clear state without zeroizing secure parameter storage 334 , which may also be written with security parameters as part of an initialization process in the clear state.
  • the ability of incident monitor module 342 to detect security incidents may be tested without zeroize module 346 zeroizing secure parameter storage 334 upon detecting a security incident.
  • indication module 348 may indicate the occurrence of the security incident.
  • indication module 348 may output at least one of an auditory indication, visual indication, or other indication to a user of computing device 300 via an output device (e.g., display, speaker, etc.) of computing device 300 to indicate the occurrence of the security incident.
  • security control module 340 may prevent record storage module 344 from recording any incident records if state value 181 indicates the zeroize state. In this manner, security control module 340 may alert a user to the detection of a security incident while preventing record storage module 344 from overwriting an incident record documenting the security incident that caused processor 310 to enter the zeroize state.
  • each of the operating states of processor 310 may cause processor 310 to operate in a manner appropriate for a different stage of the life cycle of computing device 300 .
  • the operating state of processor 310 may dictate whether processor 310 permits writing to secure parameter storage 334 , whether processor 310 permits reformatting of information read from outside of processor 310 , and/or what action to take in response to detecting a security incident.
  • the clear state may dictate that processor 310 permit writing to secure parameter storage 334 and storing incident records in response to detecting security incidents.
  • processor 310 may prevent certain security functionalities of processor 310 , such as reformatting information read from or written to storage external to processor 310 with reformatting module 225 .
  • the secure state may dictate that processor 310 permit certain security functionalities prevented in the clear state.
  • the secure state may dictate that processor 310 reformat all information read from or written to external storage and at least partially zeroize secure parameter storage 334 in response to detecting a security incident.
  • the secure state may also permit writing information to secure parameter storage.
  • the zeroize state may dictate that processor 310 prevent writing to secure parameter storage 334 and output an indication in response to detecting a security incident rather than storing an incident record.
  • the clear, secure, and zeroize states may each cause processor 310 to operate in a manner appropriate to a different portion of the life cycle of computing device 300 .
  • other examples may include additional and/or other states.
  • FIG. 4A is a block diagram of an example computing device 300 comprising an address selector 326 to set region selection bits based on a state value 181 .
  • computing device 300 may include a processor 310 , and machine-readable storage medium 350 .
  • vector controller 120 includes an address selector 326 , in addition to core module 222 described above in relation to FIG. 2 .
  • Vector controller 120 may also include formatting module 225 described above in relation to FIG. 2 .
  • core module 222 includes interrupt handler 324
  • address selector includes region determining module 328 and selection bits determining module 329 .
  • the functionalities of interrupt handler 324 , address selector 326 , and modules 328 and 329 may each be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof. Additionally, in some examples, the vector controllers of the examples of FIGS. 1-3 may each include the functionalities of vector controller 120 described herein in relation to FIG. 4A .
  • storage medium 350 includes a reset region 360 comprising a clear region 362 , a secure region 364 , and a zeroize region 366 .
  • reset region 360 is an address range within storage medium
  • each of clear, secure, and zeroize regions 362 , 364 , and 366 is an address range within reset region 360 .
  • clear region 362 may include at least a portion of clear boot information 252
  • secure region 364 may include at least a portion of secure boot information 254
  • zeroize region may include at least a portion of zeroize boot information 356 .
  • the clear, secure, and zeroize regions 362 , 364 , and 366 may include clear boot data 253 A, secure boot data 255 A, and zeroize boot data 357 A, respectively.
  • the clear boot data 253 A may be an entry address for clear boot instructions 253 B
  • the secure boot data 255 A may be an entry address for secure boot instructions 255 B
  • the zeroize boot data 357 A may be an entry address for zeroize boot instructions 357 B.
  • vector controller 120 may provide to storage medium 350 a read operation 392 to read from one of a plurality of reset vectors based on state value 181 .
  • read operation 392 may include a portion of an address on a first bus section 372 , read control signal 376 , and region selection bits 394 .
  • reset vector read requests output by vector controller 120 may each be similar to read operation 392 .
  • interrupt handler 324 may receive reset request 183 and, in response, may provide a memory access address 375 on an address bus 370 of processor 310 as part of a read operation.
  • the read operation may be a request to read from a default reset vector of interrupt handler 324
  • memory access address 375 may be the address of the default reset vector.
  • the read operation may include memory access address 375 and a read control signal 376 to indicate a read operation to storage medium 350 .
  • address bus 370 may have first and second bus sections 372 and 374 , which may provide first and second portions of an address on address bus 370 , respectively, to address selector 326 .
  • first bus section 372 includes less than all of an address on bus 370
  • second bus section 374 includes at least one bit of the address.
  • Address bus 370 may provide the first portion of an address on address bus 370 to storage medium 350 via first bus section 372 .
  • address selector 326 may receive memory access address 375 from interrupt handler 324 via address bus 370 .
  • address selector 326 may receive a first portion of memory access address 375 via first bus section 372 and receive a second portion of address 375 via second bus section 374 .
  • region determining module 328 may determine whether memory access address 375 refers to reset region 360 of storage 350 .
  • module 328 may determine whether the address 375 is an address within the address range of reset region 360 .
  • module 328 may determine whether memory access address 375 refers to reset region 360 from the first portion of address 375 , received via first bus section 372 .
  • selection bits determining module 329 may set region selection bits 394 based on state value 181 .
  • address selector 326 may provide the region selection bits 394 to storage medium 350 in place of the second portion of the memory access address output by interrupt handler 324 . In this manner, address selector 326 may substitute region selection bits 394 for the second portion of address 372 if address 375 refers to reset region 360 , in order to redirect the read request to a reset vector associated with state value 181 (i.e., the operating state of processor 310 ).
  • module 329 may set region selection bits 394 equal to the second portion of address 375 received via second bus section 374 . In this manner, storage medium 350 may receive the read request output by interrupt hander 324 if address 375 does not refer to reset region 360 .
  • region selection bits 394 may distinguish between addresses within reset region 360 .
  • region selection bits 394 set based on state value 181 , may distinguish among addresses in at least clear region 362 , secure region 364 , and zeroize region 366 .
  • the first portion of address 375 together with region selection bits 394 , set based on state value 181 may form an address in one of clear region 362 , secure region 364 , and zeroize region 366 .
  • the address formed may point to one of a portion of clear boot information 252 stored in clear region 362 , a portion of secure boot information 254 stored in secure region 364 , and a portion of zeroize boot information 356 stored in zeroize region 366 .
  • FIG. 48 is a block diagram of an example address selector 326 to set region selection bits 394 based on a state value 181 .
  • the example of FIG. 48 will be described herein in the context of a computing device architecture having a byte-addressed memory and using 32-bit addresses. However, examples described herein may be utilized in the context of other architectures as well.
  • address bus 370 may be a 32-bit address bus to communicate a 32-bit address including address bits A 0 -A 31 .
  • first bus section 372 may communicate address bits A 0 , A 1 , and A 4 -A 31
  • second bus section 374 may communicate address bits A 2 and A 3 .
  • a default reset vector of a processor may be an address pointing to the beginning of a last word (e.g., a last 4 bytes) of addressable memory.
  • the default reset vector may be the hexadecimal address 0xFFFF FFFC, which points to the first of 4 sequentially stored bytes of memory that form the last word of addressable memory.
  • reset region 360 may include hexadecimal addresses 0xFFFF FFF0 through 0xFFFF FFFF, which includes the default reset vector.
  • the clear reset vector may be the address 0xFFFF FFFC
  • the secure reset vector may be the address 0xFFFF FFF8
  • the zeroize reset vector may be the address 0xFFFF FFF4.
  • reading information from one of these reset vector may include reading 4 sequentially stored bytes beginning at the address of the reset vector.
  • the clear reset vector may be the same address as the default reset vector, and the 4 bytes beginning at 0xFFFF FFF0 may be unused.
  • addresses in reset region 360 have the common characteristic that address bits A 4 -A 31 are all logic 1 for addresses in reset region 360 .
  • region determining module 328 may determine that a memory access address 375 on address bus 370 refers to reset region 360 if each of address bits A 4 -A 31 is a logic 1.
  • module 328 may include an AND gate 432 to perform an AND operation on address bits A 4 -A 31 of first bus section 372 to determine whether memory access address 375 refers to reset region 360 .
  • address bits A 4 -A 31 may be a portion of the first portion of address 375 described above in relation to FIG. 4A .
  • AND gate 432 may output a logic 1 as region signal 435 , indicating that address 375 refers to reset region 360 . If any of bits A 4 -A 31 is not a logic 1, then AND gate 432 may output a logic 0 as region signal 435 , indicating that address 375 does not refer to reset region 360 .
  • selection bits determining module 329 may include a multiplexer 438 and two inverters 434 and 436 .
  • multiplexer 438 may receive region signal 435 , address bits A 2 and A 3 of second bus section 374 , and the respective outputs of inverters 434 and 436 .
  • Multiplexer 438 may output region selection bits 394 .
  • multiplexer 438 may set region selection bits 394 based on address bits A 2 and A 3 if region signal 435 is a logic 0, indicating that address 375 does not refer to reset region 360 .
  • multiplexer 438 may output address bits A 2 and A 3 to storage medium 350 (of FIG.
  • storage medium 350 receives the original address 375 placed on address bus 370 (e.g., by interrupt handler 324 of FIG. 4A ), if address 375 is not within reset region 360 .
  • multiplexer 438 may set region selection bits 394 based state value 181 , if region signal 435 is a logic 1, indicating that memory access address 375 refers to reset region 360 .
  • state value 181 is stored as one or more bits in state storage 112 (of FIG. 4A ), depending upon the number of possible state values.
  • the three possible values of state value 181 e.g., clear, secure, and zeroize
  • each state may have its own bit and module 329 may include logic to encode the individual bits into state bits such as state bits 481 A and 481 B.
  • a state value 181 of “00” may indicate the clear state, with state bits 481 B and 481 A both being a logic 0.
  • a state value 181 of “01” may indicate the secure state, with state bit 481 B being logic 0 and state bit 481 A being logic 1, and a state value 181 of “10” may indicate the zeroize state, with state bit 481 B being logic 1 and state bit 481 A being logic 0.
  • inverters 434 and 436 may provide inverted values of state bits 481 B and 481 A to multiplexer 438 .
  • region signal 435 is a logic 1
  • multiplexer 438 may set region selection bits 394 to be the values output by inverters 434 and 436 to thereby substitute these bits for address bits A 3 and A 2 , respectively.
  • multiplexer 438 may output “11” as region selection bits 394 , to cause vector controller 120 (of FIG. 4A ) to read from a clear reset vector, which is address 0xFFFF FFFC.
  • state value 181 indicates the secure state
  • multiplexer 438 may output “10” as region selection bits 394 , to cause vector controller 120 (of FIG. 4A ) to read from a secure reset vector, which is address 0xFFFF FFF8.
  • state value 181 indicates the zeroize state
  • multiplexer 438 may output “01” as region selection bits 394 , to cause vector controller 120 (of FIG. 4A ) to read from a zeroize reset vector, which is address 0xFFFF FFF4.
  • address selector 326 may detect a read operation having a read address referring to reset region 360 , such as a request to read a default reset vector, and redirect the read request to a state-specific reset vector based on state value 181 . Additionally, address selector 326 may allow addresses not referring to reset region 360 to be provided to storage medium 350 (of FIG. 4A ) without redirection when the initial read address does not refer to reset region 360 . In such examples, a reset vector for a state other than the current state cannot be accessed since address selector 326 may redirect read requests for the reset region to the reset vector of the current state.
  • the assignment of state bits 481 A and 481 B and the use of inverters 434 and 436 allow the clear state to have a value of “00” while also allowing the clear state reset vector to have the same address as a default reset vector (e.g., 0xFFFF FFFC).
  • a default reset vector e.g., 0xFFFF FFFC
  • different assignments of state bit values to operating states may be used, and/or inverters 434 and 436 may be omitted.
  • address selector 326 may be used to substitute region selection bits for different address bits.
  • second bus section 374 may include address bits A 12 and A 13
  • first bus section 372 includes the remaining address bits.
  • reset region 360 may be the last 16 kilobytes (KB) of storage medium 350 , with each of the three operating states having a full 4 KB block assigned to it (with one 4 KB block being unused).
  • AND gate 432 may perform the AND operation on address bits A 14 -A 31
  • region selection bits 394 may be substituted for address bits A 12 and A 13 to select among the 4 KB blocks of reset region 360 .
  • reset region 360 may include a 4 KB clear region 362 , a 4 KB secure region 352 , and a 4 KB zeroize region 366 .
  • clear region 362 may include up to 4 KB of clear boot information 252
  • secure region 352 may include up to 4 KB of secure boot information 254
  • zeroize region 366 may include up to 4 KB of zeroize boot information 356 .
  • a 4 KB block for a state other than the current state cannot be accessed since address selector 326 may redirect read requests for the reset region to the 4 KB block of the current state.
  • a different computing device architecture may be utilized.
  • examples described herein may be implemented with a word-addressed memory using 20-bit addresses.
  • a vector controller may use an address selector similar to address selector 326 of FIG. 4B , except that AND gate 432 may perform the AND operation on address bits A 2 -A 19 , and module 329 may substitute region selection bits 394 for address bits A 0 and A 1 .
  • FIG. 5 is a flowchart of an example method 500 for booting a computing device with different boot information based on a state value. Although execution of method 500 is described below with reference to processor 110 of FIG. 1 , other suitable components for execution of method 500 can be utilized (e.g., computing device 300 ). Additionally, method 500 may be implemented by logic on a processor, regardless of how the logic on the processor is implemented.
  • vector controller 120 of processor 110 may receive a state value 181 from state storage 112 .
  • state value may indicate one of a plurality of operating states of processor 110 .
  • the operating states may include a clear state associated with a clear state reset vector pointing to clear boot information, a secure state associated with a secure state reset vector pointing to secure boot information, and a zeroize state associated with a zeroize state reset vector pointing to zeroize boot information.
  • the secure boot information may have a different format than the clear boot information, as described above in relation to FIGS. 1-3 . Additionally, in some examples, the clear boot information, the secure boot information, and the zeroize boot information may be independent from one another.
  • vector controller 120 may receive reset request 183 .
  • processor 110 may, in response to reset request 183 , boot a computing device including processor 110 based on state value 181 and information stored at a reset vector associated with state value 181 .
  • processor 110 may determine at 515 whether state value 181 indicates the clear state. If so, method 500 may proceed to 520 . If not, processor 110 may determine at 525 whether state value 181 indicates the secure state. If so, method 500 may proceed to 530 . If not, processor 110 may determine at 535 whether state value 181 indicates the zeroize state. If so, method 500 may proceed to 540 . If not, method 500 may return to 515 . In other examples, method 500 may determine which the state indicated by state value 181 in a different order.
  • processor 110 may boot the computing device including processor 110 based on state value 181 indicating the clear state and based on information stored at the reset vector associated with state value 181 .
  • a given reset vector is “associated with” a given operating state of a processor if the processor is to read from the given reset vector in response to a reset vector when it is in the given operating state.
  • processor 110 is to read from a clear state reset vector when state value 181 indicates the clear state.
  • processor 110 may boot the computing device based on a portion of clear boot information (e.g. clear boot data) stored at the clear state reset vector, as described above in relation to FIGS. 1-3 . In this manner, processor 110 may boot the computing device based on the clear boot information.
  • clear boot information e.g. clear boot data
  • processor 110 may boot the computing device based on state value 181 indicating the secure state and based on information stored at a secure state reset vector associated with the secure state value. In such examples, at 530 , processor 110 may boot the computing device based on a portion of secure boot information (e.g., secure boot data) stored at the secure state reset vector, as described above in relation to FIGS. 1-3 . In this manner, processor 110 may boot the computing device based on the secure boot information.
  • processor 110 may boot the computing device based on state value 181 indicating the zeroize state and based on information stored at a zeroize state reset vector associated with the zeroize state value.
  • processor 110 may boot the computing device based on a portion of zeroize boot information (e.g., zeroize boot data) stored at the zeroize state reset vector, as described above in relation to FIGS. 2-3 . In this manner, processor 110 may boot the computing device based on the zeroize boot information.
  • zeroize boot information e.g., zeroize boot data
  • FIG. 6 is a flowchart of an example method 600 for booting a computing device with one of a plurality of sets of boot information stored in different formats based on a state value.
  • execution of method 600 is described below with reference to processor 110 of FIG. 1 , other suitable components for execution of method 600 can be utilized (e.g., computing device 300 ). Additionally, method 600 may be implemented by logic on a processor, regardless of how the logic on the processor is implemented.
  • vector controller 120 of processor 110 may receive a state value 181 from state storage 112 .
  • state value may indicate a clear state associated with a clear state reset vector pointing to clear boot information, a secure state associated with a secure state reset vector pointing to secure boot information, or a zeroize state associated with a zeroize state reset vector pointing to zeroize boot information.
  • the clear boot information may be stored in a first format
  • the secure boot information may be stored in a second format different than the first format
  • the zeroize boot information may be stored in a third format different than the first and second formats.
  • none of the first, second, and third formats is a format of information that processor 110 may operate on without first reformatting the information.
  • each of the first, second, and third formats may be an encoded or otherwise encrypted format, and not a cleartext format.
  • the clear boot information, the secure boot information, and the zeroize boot information may be independent from one another.
  • vector controller 120 may receive reset request 183 .
  • processor 110 may, in response to reset request 183 , boot a computing device including processor 110 based on state value 181 and information stored at a reset vector associated with the state value 181 .
  • processor 110 may determine at 615 whether state value 181 indicates the clear state. If so, method 600 may proceed to 620 . If not, processor 110 may determine at 635 whether state value 181 indicates the secure state. If so, method 600 may proceed to 640 . If not, processor 110 may determine at 650 whether state value 181 indicates the zeroize state. If so, method 600 may proceed to 655 . If not, method 600 may return to 615 . In other examples, method 600 may determine which the state indicated by state value 181 in a different order.
  • processor 110 may boot the computing device based on state value 181 indicating the clear state and based on information stored at a clear state reset vector associated with the clear state value.
  • processor 110 may boot the computing device based on a portion of clear boot information (e.g., clear boot data) stored at the clear state reset vector, as described above in relation to FIGS. 1-3 .
  • processor 110 may boot the computing device with the clear boot information.
  • booting the computing device with the clear boot information may include reformatting the clear boot information from the first format to a cleartext format with, for example, a formatting module of vector controller 120 , as described above in relation to FIG. 2 .
  • method 600 may proceed to 625 , where processor 110 may receive a security parameter. After receiving the security parameter, method 600 may proceed to 630 , where processor 110 may store the security parameter in a secure parameter storage of processor 110 , as described above in relation to FIG. 3 .
  • processor 110 may boot the computing device based on state value 181 indicating the secure state and based on information stored at a secure state reset vector associated with the secure state value.
  • processor 110 may boot the computing device based on a portion of secure boot information (e.g., secure boot data) stored at the secure state reset vector, as described above in relation to FIGS. 1-3 .
  • secure boot information e.g., secure boot data
  • processor 110 may boot the computing device with the secure boot information.
  • booting the computing device with the secure boot information may include reformatting the secure boot information from the second format to a cleartext format with a formatting module of vector controller 120 , as described above in relation to FIG. 2 .
  • method 600 may proceed to 645 , where processor 110 may zeroize the security parameter stored in the secure parameter storage of processor 110 in response to a security incident.
  • processor 110 may monitor processor 110 and/or the computing device including processor 110 for security incidents, as described above in relation to FIG. 3 .
  • processor 110 may zeroize at least one security parameter stored in secure parameter storage of processor 110 at 645 .
  • processor 110 may boot the computing device based on state value 181 indicating the zeroize state and based on information stored at a zeroize state reset vector associated with the zeroize state value.
  • processor 110 may boot the computing device based on a portion of zeroize boot information (e.g., zeroize boot data) stored at the zeroize state reset vector, as described above in relation to FIGS. 2-3 .
  • processor 110 may boot the computing device with the zeroize boot information.
  • booting the computing device with the zeroize boot information may include reformatting the zeroize boot information from the third format to a cleartext format with a formatting module of vector controller 120 , as described above in relation to FIG. 2 .
  • method 600 may proceed to 660 , where processor 110 may perform at least one fault diagnostic operation.
  • the operation may be performed to investigate a security incident that caused processor 110 to enter the zeroize state.
  • the operation may include analyzing and/or outputting at least one incident record stored in record storage by processor 110 when processor 110 was in the clear or secure state.
  • the operation may be implemented in the form of executable instructions encoded on a machine-readable storage medium, in the form of electronic circuitry, or a combination thereof.

Abstract

Example embodiments disclosed herein relate to reset vectors for boot information. Example embodiments include a clear state reset vector for clear boot information, and a secure state reset vector for secure boot information.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application claims priority to U.S. provisional patent application No. 61/509,078, filed on Jul. 18, 2011, which is hereby incorporated by reference herein in its entirety.
  • BACKGROUND
  • A computing device, such as a device including a processor, may interact with secret or otherwise sensitive information during operation. As such, some computing devices may operate to protect the sensitive information. For example, a computing device may encrypt sensitive information using a security parameter, such as an encryption key, stored on the device. The computing device may also operate to protect the security parameter stored on the device.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The following detailed description references the drawings, wherein:
  • FIG. 1 is a block diagram of an example processor to read boot information having different formats from different reset vectors;
  • FIG. 2 is a block diagram of an example computing system comprising a processor to retrieve boot information from different reset vectors;
  • FIG. 3 is a block diagram of an example computing device to read portions of independent boot information from a plurality of reset vectors;
  • FIG. 4A is a block diagram of an example computing device comprising an address selector to set region selection bits based on a state value;
  • FIG. 4B is a block diagram of an example address selector to set region selection bits based on a state value;
  • FIG. 5 is a flowchart of an example method for booting a computing device with different boot information based on a state value; and
  • FIG. 6 is a flowchart of an example method for booting a computing device with one of a plurality of sets of boot information stored in different formats based on a state value.
  • DETAILED DESCRIPTION
  • As noted above, a computing device may operate to protect sensitive information using security parameters stored on the computing device. To protect both the sensitive information and the security parameters, some computing device processors may have multiple operating states that may each be utilized in different stages of the life cycle of the computing device. For example, when a computing device is being developed, tested, and/or initialized in a controlled environment, a processor of the computing device may be operated in a clear state in which the processor provides little or no security for information stored on or utilized by the processor. For example, instructions executed by the processor in this clear state may be stored outside the processor in a cleartext (e.g., unencrypted, uncompressed, etc.) format.
  • When the computing device is operated in an environment in which it is vulnerable to security threats, the processor may be operated in a secure state in which the device provides more security for information stored on and/or utilized by the processor than in the clear state. For example, instructions and other information used by the processor in the secure state may be stored outside of the processor in an encoded (e.g., encrypted) format to prevent tampering with the information to gain access to security parameters stored on the processor. Additionally, if the computing device detects a breach of the device's security, the processor may zeroize its security parameters and operate thereafter in a zeroize state in which the processor provides event reporting and diagnostic functionalities until the device is returned to the controlled environment. A computing device may store information for each of these state concurrently, but only utilize the information (e.g., execute instructions) for the current state.
  • A processor having multiple operating states may use a single reset vector pointing to common boot information used to begin the process of booting the computing device, regardless of the desired operating state. This common boot information may include common boot instructions, which may determine the desired operating state for the processor and subsequently cause the processor to read and utilize information (e.g., data and/or instructions) specific to the desired operating state. In such examples, the common boot instructions may additionally determine the format in which the state-specific information is stored and prepare the processor to reformat (e.g., decrypt) the state-specific information, if it is stored in a format other than a default format for the processor. For example, if the common boot instructions determine that the secure state is the desired state, the common boot instructions may then prepare the processor to decrypt any further information read from external while in the secure state.
  • In such examples, the common boot information to which the reset vector points cannot have multiple different formats at the same time. For example, the common boot information cannot have the cleartext format of a clear state and an encrypted format of a secure state at the same time. Rather, the common boot information may be stored in a default format (e.g., cleartext, unencrypted, etc.) so that the processor may utilize the common boot information (including common boot instructions) immediately after a reset. In such examples, the processor may begin reformatting and using boot information for a given state after the common boot instructions have determined the operating state and prepared the processor to reformat the state-specific boot information.
  • However, storing common boot information in a default format for the processor, such as cleartext, may be a point of vulnerability for the security of the processor. For example, an attacker may readily modify or replace cleartext boot instructions to thereby cause the processor to enter the wrong operating state. Such altered or replaced instructions may cause the processor to enter a clear state when the common boot instructions would cause the processor to enter the secure state. In such examples, the attacker may be able to gain unauthorized access to security parameters stored on the processor. Additionally, an attacker may learn how to set the state of the processor by viewing instructions, stored in cleartext, for setting the operating state of the processor.
  • To address these issues, examples disclosed herein include a processor providing separate reset vectors for different operating states of the processor, and providing processor logic-based selection of and reading from one of the reset vectors based on the operating state of the processor. In some examples, each of the reset vectors may point to a first portion of boot information for a different operating state of the processor. In such examples, the boot information for different operating states, including a first piece of boot information accessed for each state, may be stored in different formats. For example, a reset vector for a secure state may point to encrypted boot information and a reset vector for a clear state may point to unencrypted boot information. As such, the use of vulnerable common boot information may be eliminated.
  • As noted above, examples disclosed herein provide processor logic based selection of and reading from a reset vector. In such examples, logic of the processor may select and read from a reset vector in response to a reset before retrieving any instruction stored outside of the processor. By providing processor logic-based selection of the reset vector, examples disclosed herein may select the reset vector pointing to appropriately formatted boot information for the desired operating state without first loading any instruction stored outside of the processor. For example, processor logic may determine an appropriate reset vector and reformatting method, if any, from an indication of the operating state stored on the processor. In such examples, a processor in the secure state may begin reading and reformatting encoded boot information immediately after a reset request without first reading and utilizing vulnerable common boot instructions to determine the current state and prepare the processor to appropriately reformat state-specific information. As such, all information for the secure state that is stored outside the processor may be stored in an encoded (e.g., encrypted) format, thereby making it more difficult to tamper with information (e.g., instructions) for the secure state to gain access to security parameters stored on the processor.
  • Referring now to the drawings, FIG. 1 is a block diagram of an example processor 110 to read boot information having different formats from different reset vectors. As used herein, a “processor” may be at least one integrated circuit (IC), such as at least one semiconductor-based microprocessor, including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA) configured to retrieve and execute instructions stored on a machine-readable storage medium, other electronic circuitry suitable for the retrieval and execution of such instructions, or a combination thereof.
  • In the example of FIG. 1, processor 110 includes state storage 112 and a vector controller 120. As used herein, “storage” may be any type of memory or other electronic circuitry for storing data in any suitable format. In some examples, state storage 112 may include at least one register of non-volatile memory. State storage 112 may store a state value 181 indicating an operating state of processor 110. As used herein, an “operating state” of a processor dictates, for each of a plurality of processor functionalities, whether the processor is to permit or prevent the functionality.
  • In the example of FIG. 1, the operating states of processor 110 include at least a clear state and a secure state. Other examples may include additional and/or different operating states. For example, the operating state of processor 110 may be the clear state when state storage 112 stores a clear state value, and may be the secure state when state storage 112 stores a secure state value different than the clear state value. As used herein, a “clear state” of a processor may be a state in which the processor permits functionalities for the development, initialization and/or testing of the processor. In some examples, a processor in the clear state may permit the storing of security parameters in secure parameter storage of the processor, but permit few or no security functionalities of the processor. Additionally, as used herein, a “secure state” of a processor may be a state in which the processor permits the use of at least some security functionalities of the processor not permitted in the clear state.
  • In some examples, vector controller 120 may receive state value 181 from state storage 112. As used herein, a “vector controller” is a module of a processor including logic on the processor for selecting and reading from one of a plurality of reset vectors based on a state value of the processor, in response to a reset request, without first reading information from outside of the processor. In some examples, the functionality of vector controller 120 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium of processor 110, or a combination thereof. In such examples, the vector controller may provide processor logic-based selection of and reading from one of a plurality of reset vectors regardless of how the logic on the processor is implemented.
  • Additionally, as used herein, a “reset vector” is an address from which a processor may first read or otherwise retrieve information from a machine-readable storage medium outside of the processor after undergoing a reset. As used herein, to read “from” a reset vector means to read information stored at the address of the reset vector or to read information from a sequentially-addressed portion of a storage medium starting at the address of the reset vector. For example, in the context of word-addressed storage (e.g., memory), to read information from a reset vector may be to read the word stored at the address of the reset vector. In other examples, in the context of byte-addressed storage, to read information from a reset vector may be to read a word (e.g., 4 bytes) stored at a plurality of sequentially-addressed bytes of the storage beginning at the address of the reset vector. Additionally, as used herein, information stored “at” a reset vector means information stored at the address of the reset vector or information stored at sequential addresses of a storage medium starting at the address of the reset vector. As used herein, a reset vector may be said to “point to” information stored in a storage medium at the address of the reset vector.
  • In some examples, the information stored at a reset vector may be an entry address for a set of boot instructions for booting a computing device including the processor. In such examples, the processor may boot the computing device by executing the boot instructions starting with the instructions at the entry address stored at the reset vector. As used herein, an “entry address” is the address of a point of entry into a set of instructions executable by the processor (e.g., a program, etc.). Also, as used herein, a “machine-readable storage medium” may be any electronic, magnetic, optical, or other physical storage to contain or store information such as executable instructions, data, and the like. For example, any machine-readable storage medium described herein may be any of Random Access Memory (RAM), flash memory, a storage drive (e.g., a hard disk), a Compact Disc Read Only Memory (CD-ROM), and the like, or a combination thereof. Further, any machine-readable storage medium described herein may be non-transitory.
  • In addition to receiving state value 181, vector controller 120 may also receive a reset request 183. In some examples, reset request 183 may be generated by instructions executed by processor 110 (e.g., a software generated reset). In other examples, reset request 183 may be received from outside of processor 110. In response to reset request 183, vector controller 120 may read boot information from one of a plurality of reset vectors selected based on state value 181. As used herein, “boot information” is information that may be used by a processor to boot a computing device including the processor. In some examples, the boot information may include at least one of boot instructions and boot data.
  • As used herein, “boot instructions” area set of instructions that may be executed by a processor to boot a computing device including the processor. In some examples, a set of boot instructions may be the first instructions executed by the processor after a reset of the processor. Boot instructions may include, for example, instructions for testing and/or configuring components and/or functionalities of the computing device. In such examples, the components of the computing device to be tested and/or configured may include the processor, memory, a memory management unit, cryptographic functionalities, and the like, or a combination thereof. Additionally, as used herein, “boot data” is any data (e.g., addresses, etc.) that may be used by a processor of a computing device, along with boot instructions, to boot the computing device. In some examples, boot data may include an address at which a first instruction of a set of boot instructions is stored in a storage medium outside of the processor. In such examples, a reset vector may point to boot data including an entry address for a set of boot instructions, which may be the address of a first instruction of the set of boot instructions. In such examples, a vector controller 120 may read this boot data (e.g., the entry address for the boot instructions) from a reset vector in response to a reset request.
  • In the example of FIG. 1, in response to reset request 183, vector controller 120 may read a portion of clear boot information from a clear state reset vector, if state value 181 indicates a clear state. For example, vector controller 120 may provide, to a machine-readable storage medium storing the clear boot information, a read request 184 to read the portion of the clear boot information from the clear state reset vector. In such examples, the clear state reset vector may be the read address of read request 184. In some examples, the clear boot information may include a set of clear boot instructions and clear boot data. The clear boot data may include, for example, an entry address for the clear boot instructions, and this clear boot data may be stored in the storage medium at the address of the clear reset vector. In such examples, the portion of the clear boot information read from the clear state reset vector by vector controller 120 may be clear boot data including the entry address for the clear boot instructions, which may be an address at which one of the clear boot instructions is stored. In some examples, processor 110 may boot the computing device including processor 110 by executing the clear boot instructions beginning with the instruction at the entry address read from the clear state reset vector.
  • If state value 181 indicates a secure state, then, in response to reset request 183, vector controller 120 may read a portion of secure boot information from a secure state reset vector. For example, vector controller 120 may provide, to a machine-readable storage medium storing the secure boot information, a read request 186 to read the portion of the secure boot information from the secure state reset vector. In such examples, the secure state reset vector may be the read address of read request 186. In some examples, the secure boot information may include a set of secure boot instructions and secure boot data. In such examples, the secure boot data may include, for example, an entry address for the secure boot instructions, and this secure boot data may be stored in the storage medium at the address of the secure reset vector. In such examples, the portion of the secure boot information read from the secure state reset vector by vector controller 120 may be secure boot data including the entry address for the secure boot instructions, which may be an address at which one of the secure boot instructions is stored. In some examples, processor 110 may boot the computing device including processor 110 by executing the secure boot instructions beginning with the instruction at the entry address read from the secure state reset vector.
  • In some examples, vector controller 120 may select one of a plurality of reset vectors in response to reset request 183 by selectively altering an address of a read request generated by processor 110. For example, vector controller 120 may include a core module of processor 110 and, in response to reset request 183, the core module may output a read request having as the read address a default reset vector for the core module (e.g., for an interrupt handler of the core module). In such examples, vector controller 120 may determine that a read address on an address bus of processor 110 refers to a reset region of a machine-readable storage medium, and may selectively substitute at least one region selection bit, set based on state value 181, for at least one bit of the address on the address bus. In this manner, vector controller 120 may selectively alter the address of a read request provided in response to reset request 183 to thereby read from a reset vector associated with state value 181 in response to reset request 183. In other examples, vector controller 120 may select the reset vector in response to reset request 183 in other ways. For example, a core module included in vector controller 120 may receive state value 181 and select one of a plurality of state-specific reset vectors stored in the core module in response to reset request 183. In such examples, the state-specific reset vectors may each be stored in non-volatile storage of the core module or hard-coded in logic of the core module. In such examples, the core module may, in response to reset request 183, output a read request having a reset vector associated with state value 181 as the read address.
  • In some examples, the clear boot information may have a first format, while the secure boot information has a second format different than the first format. For example, the clear boot information may be stored in a cleartext or an otherwise unencrypted format, while the secure boot information may be stored in an encrypted format. As used herein, information in a “cleartext” format is information that a processor receiving the information is configured to execute or otherwise operate on without first reformatting (e.g., decrypting, decoding, etc.) the instruction. For example, an instruction in a cleartext format may be an instruction that the processor may execute without reformatting, and an address in a cleartext format may be an address from which the processor may read without first reformatting the address. Also, as used herein, information in an “encrypted” format is information in a format that a processor receiving the information may execute or otherwise operate on after decrypting the instruction. Additionally, in some examples, all information for a given state stored outside of processor 110 may have the same format. For example, all information (e.g., data, instructions) that may be utilized by processor 110 in the clear state, including the clear boot information and information and/or executable instructions for other clear state applications, may be stored outside the processor in the same format (e.g., the first format). Additionally, in some examples, all information that may be utilized by processor 110 in the secure state, including the secure boot information and information and/or executable instructions for other secure state applications, may be stored outside the processor in the same format (e.g., the second format).
  • In some examples, vector controller 120 may include a formatting module that may determine whether to reformat information read from outside of processor 110 based on state value 181. In such examples, when the state value 181 indicates the secure state, the formatting module may decrypt the secure boot instructions read from outside of processor 110. In other examples, the first and second formats may be any two formats different from one another. In some examples, the first and second formats may both be formats other than cleartext. For example, information in the first format may be encrypted or otherwise encoded (e.g., compressed, etc.) in any manner different than the manner in which information in the second format is encrypted or otherwise encoded. In some examples, the first and second formats may be different encrypted formats. In such examples, information in the first and second formats may be encrypted differently (e.g., using different encryption formats and/or different encryption keys, etc.).
  • In examples described above, a processor may read boot information from different reset vectors based on an operating state of the processor in response to a reset request. By selecting a state-specific reset vector based on the operating state with logic of the processor, the processor may select an appropriate reset vector and begin reading state-specific boot information in response to a reset request before reading any other information from outside of the processor. Additionally, the processor may include a reformatting module to selectively reformat received information based on the operating state of the processor. In such examples, the processor may, in different operating states, process differently formatted instructions beginning with a very first instruction read from outside the processor after a reset. In this manner, examples described herein may eliminate the use of vulnerable, cleartext common boot instructions.
  • FIG. 2 is a block diagram of an example computing system 295 comprising a processor 110 to retrieve boot information from different reset vectors. Computing system 295 includes processor 110 and a machine-readable storage medium 250. In the example of FIG. 2, storage medium 250 includes clear boot information 252 having a first format, secure boot information 254 having a second format, and zeroize boot information 256. Clear boot information 252 may include clear boot data 253A and clear boot instructions 253B each having the first format, secure boot information 254 may include secure boot data 255A and secure boot instructions 255B each having the second format, and zeroize boot information 256 may include zeroize boot data 257A and zeroize boot instructions 257B.
  • In the example of FIG. 2, processor 110 includes state storage 112 and vector controller 120, as described above in relation to FIG. 1. Also as described above in relation to FIG. 1, vector controller 120 may provide read requests 184 and 186 to a machine-readable storage medium. In response to a valid read request, storage medium 250 may provide, to processor 110, information 287 stored at the address indicated by the read request.
  • In the example of FIG. 2, in response to reset request 183, vector controller 120 may provide read request 184 to storage medium 250 to read a portion of clear boot information 252 having the first format from a clear state reset vector, if state value 181 indicates the clear state. In some examples, the portion of clear boot information 252 read from the clear state reset vector may be clear boot data 253A, which may include an entry address for clear boot instructions 253B. In such examples, processor 110 may boot a computing device including processor 110 with clear boot instructions 253B after reading clear boot data 253A from the clear state reset vector. For example, after reading clear boot data 253A from the clear state reset vector, processor 110 may begin executing clear boot instructions 253B beginning with a clear boot instruction stored at the entry address stored at the clear state reset vector.
  • If state value 181 indicates the secure state, vector controller 120 may, in response to reset request 183, provide read request 186 to storage medium 250 to read a portion of secure boot information 254 having the second format from a secure state reset vector. In some examples, the portion of secure boot information 252 read from the secure state reset vector may be secure boot data 255A, which may include an entry address for secure boot instructions 255B. In such examples, processor 110 may boot a computing device including processor 110 with secure boot instructions 255B after reading secure boot data 255A from the secure state reset vector. For example, after reading secure boot data 255A from the secure state reset vector, processor 110 may begin executing secure boot instructions 255B beginning with a secure boot instruction stored at the entry address stored at the secure state reset vector.
  • In some examples, prior to executing secure boo instructions 255B, processor 110 may verify that secure boot information 254 has not been altered by checking at least some of secure boot information 254 against validation data, such as a digital signature, of secure boot information 254. As used herein, “validation data” may be any type of data that may be derived from a collection of information and subsequently used to determine whether the information has been altered since generation of the validation data. In some examples, at least some of secure boot information 254 may be stored on processor 110 (e.g., in a cache) until processor 110 verifies that validation data derived from the stored information matches the validation data included in the secure boot information 254. In some examples, the verification data may be derived using hashing, processes used for error detection (e.g., processes used to generate a checksum, a cyclic redundancy check (CRC), etc.), or the like. If the derived validation data matches the validation data of boot information 254, the instructions may be executed, and otherwise not. In some examples, any state-specific information stored on storage medium 250 may include validation data for the information, and processor 110 may verify the validation data prior to utilizing some or all of the information.
  • In some examples, vector controller 120 includes a core module 222 and a formatting module 225 including an encryption module 227. In such examples, the functionalities of modules 222, 225, and 227 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof. In some examples, core module 222 may include or implement the functionalities of a CPU core. As used herein, a “CPU core” is a component of a processor capable of at least executing instructions. In some examples, a CPU core may include at least one of an arithmetic logic unit (ALU), an interrupt handler, a fetch controller, a data write-back controller, a floating-point unit, or a combination thereof. In some examples, core module 222 may execute or otherwise operate on information having the first format without this information first being reformatted. For example, core module 222 may execute instructions having the first format and may operate on data (e.g., addresses) having the first format. In some examples, the first format may be a cleartext format.
  • In the example of FIG. 2, formatting module 225 may reformat information received by processor 110 based on state value 181 of processor 110. In some examples, information read from or written to storage medium 250 by processor 110 may pass through formatting module 225. In such examples, formatting module 225 may have multiple operating modes, which may be selected based on state value 181. For example, formatting module 225 may have a bypass mode, in which formatting module 225 forwards received information without reformatting the information, and at least one formatting mode, in which formatting module 225 reformats received information. In some examples, formatting module 225 may have multiple different formatting modes associated with different operating states of processor 110 and different formats associated with those operating states.
  • In the example of FIG. 2, information used by processor 110 in the clear state, including at least clear boot information 252, for example, may be stored outside of processor 110 in the first format. In such examples, information 287 read from storage medium 250 when processor 110 is in the clear state (e.g., clear boot information 252) may have the first format. As such, in some examples, information read in the clear state may be passed to core module 222 without first being reformatted. Accordingly, in some examples, formatting module 225 may operate in a bypass mode in which it outputs received information without reformatting the information, if state value 181 indicates a clear state. In such examples, formatting module 225 may receive information 287 and output the received information in the format in which it was received, if state value 181 indicates the clear state.
  • Additionally, in some examples, information used by processor 110 in the secure state, including at least secure boot information 254, for example, may be stored outside of processor 110 in the second format. As such, information 287 read from storage medium 250 when processor 110 is in the secure state (e.g., secure boot information 254) may have the second format. Accordingly, in some examples, formatting module 225 may reformat information 287 received from storage medium 250 from the second format to the first format, if state value 181 indicates the secure state.
  • In some examples, formatting module 225 may include an encryption module 227 to encrypt and decrypt information. In such examples, the second format may be an encrypted format for protecting the information for the secure state when stored outside of processor 110, and the first format may be an unencrypted format, such as a cleartext format. In such examples, encryption module 227 may decrypt received information 287 from an encrypted second format to the unencrypted first format, if state value 181 indicates the secure state. In examples described herein, storing information used in the secure state in an encrypted format when stored outside of processor 110 may provide additional security for the secure state of processor 110. For example, the information may be kept secret when stored outside of the processor when stored in an encrypted format. Additionally, it may be difficult to effectively replace or modify sections of code stored in an encrypted format.
  • Additionally, in some examples, if state value 181 indicates the secure state, formatting module 225 may reformat information 289 to be written to storage medium 250 from the first format to the second format (e.g., encrypt the information) before writing the information. In such examples, if the information written is subsequently read by processor 110 in the secure state, then formatting module 225 may reformat the information from the second to the first format.
  • By selecting an operating mode based on a state value 181 of state storage 112, formatting module 225 may allow all information utilized by a processor in a given mode to be stored outside of the processor in a state-specific format. For example, all information for the clear state, including the information stored at the clear state reset vector, may be stored in first format (e.g., a cleartext format), while all information for the secure state, including the information stored at the secure state reset vector, may be stored in a second format (e.g., an encrypted format). In such examples, formatting module 225 may correctly reformat (or bypass) all information read in a given operating state of the processor, beginning with information read from a state-specific reset vector, based on state value 181. In this manner, examples disclosed herein may eliminate the use of common boot information, and instead allow state-specific boot information to be used in each operating state. Further, in some examples, the state-specific boot information for different states may have different, state-specific formats.
  • Additionally, in some examples, the operating states of processor 110 may include a zeroize state in addition to the clear and secure states. In such examples, the operating state of processor 110 may be the zeroize state when state storage 112 stores a zeroize state value, different that the clear and secure state values, as state value 181. As used herein, a “zeroize state” of a processor may be a state entered by the processor after detection of a security incident and in which the processor prevents the storage of security parameters and permits diagnostic functionalities of the processor. Additionally, in some examples, a processor in the zeroize state may permit event reporting functionalities, but permit few or no security functionalities of processor 110.
  • In the example of FIG. 2, in response to reset request 183, vector controller 120 may provide a read request 288 to storage medium 250 to read a portion of zeroize boot information 256 from a zeroize state reset vector, if state value 181 indicates the zeroize state. In some examples, the portion of zeroize boot information 256 read from the zeroize state reset vector may be zeroize boot data 257A, which may include an entry address for secure boot instructions 257B. In such examples, processor 110 may boot a computing device including processor 110 with zeroize boot instructions 257B after reading zeroize boot data 257A from the zeroize state reset vector. For example, after reading zeroize boot data 257A from the zeroize state reset vector, processor 110 may begin executing zeroize boot instructions 257B beginning with a zeroize boot instruction stored at the entry address stored at the zeroize state reset vector.
  • In some examples, zeroize boot information 256 may have a third format different than the first and second formats. In such examples, zeroize boot information 256 may be encoded, encrypted, or otherwise formatted differently than clear and secure boot information 252 and 254. For example, when clear boot information 252 is in a cleartext format, and secure boot information 254 is encrypted, zeroize boot information 256 may be encrypted differently than secure boot information 254 (e.g., encrypted with a different key or by a different process), or may be compressed or otherwise encoded by a suitable process other than encryption. In other examples, the first, second, and third formats may be any three formats different from one another. In some examples, all three formats may be formats other than cleartext. For example, information in the first, second, and third formats may each be encrypted, encoded, or otherwise formatted such that the three formats are different from one another.
  • In some examples, information used by processor 110 in the zeroize state, including at least zeroize boot information 256, for example, may be stored outside of processor 110 in the third format. In such examples, information 287 read from storage medium 250 when processor 110 is in the zeroize state (e.g., zeroize boot information 256) may have the third format. Accordingly, in some examples, formatting module 225 may reformat information 287 received from storage medium 250 from the third format to the first format, if state value 181 indicates the zeroize state. In such examples, formatting module 225 may have multiple formatting modes. For example, formatting module 225 may operate in a first formatting mode to reformat information from the second to the first format, if state value 181 indicates the secure state. Additionally, formatting module 225 may operate in a second formatting mode to reformat information from the third to the first format, if state value 181 indicates the zeroize state. In other examples, zeroize boot instructions 256 may have the same format as clear boot instructions 252 (i.e., the first format). In such examples, formatting module 225 may enter a bypass mode if state value 181 indicates the zeroize state. In some examples, vector controller 120 may select one of the plurality of reset vectors in response to reset request 183 in any manner described above in relation to FIG. 1. For example, vector controller 120 may select one of the plurality of reset vectors in response to reset request 183 by selectively altering an address of a read request generated by processor 110, as described above in relation to FIG. 1.
  • Additionally, in some examples, all information for a given state stored outside of processor 110 may have the same format, as described above in relation to FIG. 1. For example, all information that may be utilized by processor 110 in the clear state may be stored outside the processor in the same format, and all information that may be utilized by processor 110 in the secure state may be stored outside the processor in the same format. Additionally, in some examples, all information (e.g., data, instructions) that may be utilized by processor 110 in the zeroize state, including the zeroize boot information and information and/or executable instructions for other zeroize state applications, may be stored outside the processor in the same format (e.g., the third format). Also, while examples are described herein in the context of clear, secure, and zeroize states, other examples may include additional and/or other states.
  • FIG. 3 is a block diagram of an example computing device 300 to read portions of independent boot information from a plurality of reset vectors. As used herein, a “computing device” may be a desktop or, notebook computer, a tablet computer, a computer networking device (e.g., a hardware security module), a server, or any other device or equipment (e.g., an automated teller machine (ATM), etc.) including a processor. In some examples, computing device 300 may be any of the devices noted above. Computing device 300 may include a processor 310 and a machine-readable storage medium 350. Processor 310 may include state storage 112 and a vector controller 120, as described above in relation to FIGS. 1 and 2. In the example of FIG. 3, processor 310 also includes a storage control module 332, secure parameter storage 334, and a security control module 340. Security control module 340 may include an incident monitor module 342, a record storage module 344, a zeroize module 346, and an indication module 348. In some examples, the functionalities of modules 332, 340, 342, 344, 346, and 348 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.
  • In some examples, storage medium 350 may include clear boot information 252 and secure boot information 254, as described above in relation to FIG. 2. In such examples, clear boot information 252 may have a first format and secure boot information 254 may have a second format different than the first format, as described above in relation to FIG. 2. In the example of FIG. 3, storage medium may further include zeroize boot information 356, which may be similar to zeroize boot information 256, except that it may have the first format rather than a third format, as described above in relation to FIG. 2. In such examples, zeroize boot data 357A and zeroize boot instructions 357B may be the same as zeroize boot data 257A and zeroize boot instructions 257B, respectively, except stored in different formats.
  • In the example of FIG. 3, state storage 112 may store state value 181 indicating an operating state of processor 310, as described above in relation to FIGS. 1 and 2. The operating states of processor 310 may include at least the clear state, the secure state, and the zeroize state. In some examples, each of the operating states of processor 310 may cause processor 310 to operate in a manner appropriate for different stages of the life cycle of computing device 300. For example, during development, testing, and/or initialization of computing device 300 in a controlled environment, processor 310 may be operated in the clear state in which few or no security functionalities of processor 310 are permitted. In an environment in which computing device 300 is vulnerable to security threats, processor 310 may operate in the secure state, in which processor 310 permits the operation of security functionalities not permitted in the clear state to protect information stored on or utilized by processor 310. In some examples, in the secure state, processor 310 may zeroize at least one security parameter in secure parameter storage 334 and enter a zeroize state in response to the detection of a security incident. In the zeroize state, processor 310 may permit diagnostic functionalities for investigating the security incident that caused processor 310 to enter the zeroize state and prevents the storage of security parameters in secure parameter storage 334.
  • In some examples, in response to reset request 183, vector controller 120 may provide a read request 384 to storage medium 350 to read a portion of clear boot information 252 from a clear state reset vector, if state value 181 indicates the clear state. The read address of read request 384 may be the clear state reset vector. In some examples, the portion of clear boot information 252 read from the clear state reset vector may be clear boot data 253A, which may include an entry address for clear boot instructions 253B. In such examples, processor 110 may boot computing device 300 with clear boot instructions 253B after reading clear boot data 253A from the clear state reset vector, as described above in relation to FIG. 2. In some examples, if state value 181 indicates the secure state, vector controller 120 may, in response to reset request 183, provide read request 386 to storage medium 350 to read a portion of secure boot information 254 from a secure state reset vector. The read address of read request 386 may be the secure state reset vector. In some examples, the portion of secure boot information 252 read from the secure state reset vector may be secure boot data 255A, which may include an entry, address for secure boot instructions 255B. In such examples, processor 110 may boot computing device 300 with secure boot instructions 255B after reading secure boot data 255A from the secure state reset vector, as described above in relation to FIG. 2.
  • Additionally, in the example of FIG. 3, in response to reset request 183, vector controller 120 may provide a read request 388 to storage medium 250 to read a portion of zeroize boot information 356 from a zeroize state reset vector, if state value 181 indicates the zeroize state. The read address of read request 388 may be the zeroize state reset vector. In some examples, the portion of zeroize boot information 356 read from the zeroize state reset vector may be zeroize boot data 357A, which may include an entry address for secure boot instructions 357B. In such examples, processor 310 may boot computing device 300 with zeroize boot instructions 3578 after reading zeroize boot data 357A from the zeroize state reset vector, as described above in relation to zeroize boot instructions 356 of FIG. 2. In some examples, vector controller 120 may select one of the plurality of state-specific reset vectors in response to reset request 183 in any manner described above in relation to FIG. 1.
  • In some examples, vector controller 120 may include formatting module 225, as described above in relation to FIG. 2. In such examples, formatting module 225 may reformat information 287 read from storage medium 250, as described above in relation to FIG. 2. In some examples, as noted above, clear and zeroize boot information 252 and 356 may have the first format, while the secure boot information 254 may have a second format different than the first format. For example, the clear and zeroize boot information 252 and 356 may be stored in a cleartext or an otherwise unencrypted format, while secure boot information 254 may be stored in an encrypted format. In such examples, formatting module 225 may operate in a bypass mode if state value 181 indicates the clear or zeroize state. In other examples, clear boot information 252, secure boot information 254, and zeroize boot information 356 may each be stored in a different format on storage medium 350.
  • Additionally, in some examples, all information for a given state stored outside of processor 110 may have the same format, as described above in relation to FIGS. 1 and 2. For example, all information that may be utilized by processor 110 in the clear state may be stored in the same format, all information that may be utilized by processor 110 in the secure state may be stored in the same format, and all information that may be utilized by processor 110 in the zeroize state may be stored in the same format.
  • In the example of FIG. 3, clear boot information 252, secure boot information 254, and zeroize boot information 356 are independent from one another. Moreover, in such examples, clear, secure, and zeroize boot instructions 253B, 255B, and 357B are independent from one another. In such examples, clear boot information 252, secure boot information 254, and zeroize boot information 356 each include a full set of boot data and instructions that may be used to boot computing device 300. In some examples, each of clear boot information 252, secure boot information 254, and zeroize boot information 356 is sufficient for performing a cold boot of computing device 300 (i.e., to boot computing device 300 from an off state after power is applied). In some examples, each of clear, secure, and zeroize boot instructions 253B, 255B, and 357B may include instructions for testing and/or configuring components and/or functionalities of computing device 300, and for otherwise preparing computing device 300 to operate in accordance with a current operating state of processor 310, as indicated by state value 181.
  • In the example of FIG. 3, processor 310 includes secure parameter storage 334 and a storage control module 332. In some examples, secure parameter storage 334 may store at least one security parameter for processor 310. As used herein, a “security parameter” is information used by a computing device for cryptography, authentication, or any other security functionality of the computing device. Some examples of security parameters may include, for example, cryptographic keys, initialization vectors, personal identification numbers (PINs), public exponents for cryptography, and the like. In the example of FIG. 3, secure parameter storage 334 is storage in which processor 310 may store security parameters for use by processor 310.
  • In some examples, storage control module 332 may control interaction with secure parameter storage 334 in accordance with the operating state of processor 310. In the example of FIG. 3, storage control module 332 may permit processor 310 to write security parameters to secure parameter storage 334 based on state value 181. In some examples, storage control module 332 may permit information, such as security parameters, to be written to secure parameter storage 334 if state value 181 indicates the clear state or the secure state. In such examples, in the clear and secure states, processor 310 may allow a host device, external to processor 310 and computing device 300, to write a security parameter 385 to secure parameter storage 334.
  • Additionally, in some examples, storage control module 332 may prevent information, such as security parameters, from being written to secure parameter storage 334 if state value 181 indicates the zeroize state. For example, storage control module 332 may detect an operation to write to secure parameter storage 334. If state value 181 indicates the clear or secure state, storage control module 332 may take no action to prevent the write operation. If state value 181 indicates the zeroize state, storage control module 332 may prevent the write operation by, for example, preventing a write control signal from being asserted or by causing a processor exception to prevent the write operation.
  • In some examples, security control module 340 may control the response of processor 310 to a security incident based on the operating state of processor 310. In the example of FIG. 3, security control module includes an incident monitor module 342 that may monitor processor 310 for security incidents. As used herein, a “security incident” is an event affecting or otherwise related to a computing device or a component thereof that may, alone or in combination with at least one other event, increase the vulnerability of information stored on the computing device. For example, a security incident may be a change in a condition or configuration of a computing device or receipt of any signal by the computing device that may, alone or in combination with at least one other change or signal, increase the vulnerability of information stored on the computing device. For example, incident monitor module 342 may monitor processor 310 and/or computing device 300 for security incidents. In some examples, incident monitor module 342 may detect a security incident upon determining that an actual or attempted physical tampering with or probing of processor 310 has occurred, upon determining that a signal received by processor 310 is part of an attack (e.g., is a forged signal, a replayed signal, etc.), upon receiving a signal indicating the occurrence of a security incident from another incident monitor external to processor 310, and the like.
  • In the example of FIG. 3, in response to incident monitor module 342 detecting a security incident, zeroize module 346 may zeroize at least one security parameter stored in secure parameter storage 334 if state value 181 indicates the secure state. As used herein, “zeroization” of information includes at least one of erasing and overwriting the information at least once. Zeroization module 346 may erase and/or overwrite some or all of the contents of secure parameter storage 334. In some examples, to zeroize security parameters, zeroization module 346 may overwrite each bit of the security parameters multiple times. For example, module 346 may overwrite each bit of the security parameters with a first logic value (e.g., 0), then with a second logic value (e.g., 1), and then overwrite the security parameters with a combination of logic 1's and logic 0's. Also, in some examples, module 346 may erase security parameters and then take further actions to prevent the recovery of the erased parameters, such as overwriting the erased parameters at least once, to complete the zeroization of the security parameters. In addition to zeroizing storage 334, record storage module 344 may also store an incident record, as described above in relation to the clear state, if state value 181 indicates the secure state.
  • If state value 181 indicates the clear state, then record storage module 344 may store an incident record in response to incident monitor module 342 detecting a security incident. In such examples, record storage module 344 may store the incident record in record storage on or external to processor 310. The incident record may include details of the security incident, such as the date, time, event that triggered the detection of the security incident, and any other details that may be used to diagnose, study or further determine the cause of the security incident. Additionally, security control module 340 may prevent zeroize module 346 from zeroizing of any parameter of secure parameter storage 334 if state value 181 indicates the clear state. In this manner, processor 310 may be tested in the clear state without zeroizing secure parameter storage 334, which may also be written with security parameters as part of an initialization process in the clear state. In such examples, the ability of incident monitor module 342 to detect security incidents may be tested without zeroize module 346 zeroizing secure parameter storage 334 upon detecting a security incident.
  • If state value 181 indicates the zeroize state, then, in response to incident monitor module 342 detecting a security incident, indication module 348 may indicate the occurrence of the security incident. In some examples, indication module 348 may output at least one of an auditory indication, visual indication, or other indication to a user of computing device 300 via an output device (e.g., display, speaker, etc.) of computing device 300 to indicate the occurrence of the security incident. Additionally, in some examples, security control module 340 may prevent record storage module 344 from recording any incident records if state value 181 indicates the zeroize state. In this manner, security control module 340 may alert a user to the detection of a security incident while preventing record storage module 344 from overwriting an incident record documenting the security incident that caused processor 310 to enter the zeroize state.
  • As noted above, each of the operating states of processor 310 may cause processor 310 to operate in a manner appropriate for a different stage of the life cycle of computing device 300. For example, as described above in relation to FIG. 3, the operating state of processor 310 may dictate whether processor 310 permits writing to secure parameter storage 334, whether processor 310 permits reformatting of information read from outside of processor 310, and/or what action to take in response to detecting a security incident. In some examples, the clear state may dictate that processor 310 permit writing to secure parameter storage 334 and storing incident records in response to detecting security incidents. Additionally, in the clear state, processor 310 may prevent certain security functionalities of processor 310, such as reformatting information read from or written to storage external to processor 310 with reformatting module 225.
  • Additionally, in some examples, the secure state may dictate that processor 310 permit certain security functionalities prevented in the clear state. For example, the secure state may dictate that processor 310 reformat all information read from or written to external storage and at least partially zeroize secure parameter storage 334 in response to detecting a security incident. The secure state may also permit writing information to secure parameter storage. Moreover, in some examples, the zeroize state may dictate that processor 310 prevent writing to secure parameter storage 334 and output an indication in response to detecting a security incident rather than storing an incident record. As such, the clear, secure, and zeroize states may each cause processor 310 to operate in a manner appropriate to a different portion of the life cycle of computing device 300. Also, while examples are described herein in the context of clear, secure, and zeroize states, other examples may include additional and/or other states.
  • FIG. 4A is a block diagram of an example computing device 300 comprising an address selector 326 to set region selection bits based on a state value 181. As described above in relation to FIG. 3, computing device 300 may include a processor 310, and machine-readable storage medium 350. In the example of FIG. 4A, vector controller 120 includes an address selector 326, in addition to core module 222 described above in relation to FIG. 2. Vector controller 120 may also include formatting module 225 described above in relation to FIG. 2. In the example of FIG. 4A, core module 222 includes interrupt handler 324, and address selector includes region determining module 328 and selection bits determining module 329. In some examples, the functionalities of interrupt handler 324, address selector 326, and modules 328 and 329 may each be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof. Additionally, in some examples, the vector controllers of the examples of FIGS. 1-3 may each include the functionalities of vector controller 120 described herein in relation to FIG. 4A.
  • In the example of FIG. 4A, storage medium 350 includes a reset region 360 comprising a clear region 362, a secure region 364, and a zeroize region 366. In some examples, reset region 360 is an address range within storage medium, and each of clear, secure, and zeroize regions 362, 364, and 366 is an address range within reset region 360. In the example of FIG. 4A, clear region 362 may include at least a portion of clear boot information 252, secure region 364 may include at least a portion of secure boot information 254, and zeroize region may include at least a portion of zeroize boot information 356. In some examples, the clear, secure, and zeroize regions 362, 364, and 366 may include clear boot data 253A, secure boot data 255A, and zeroize boot data 357A, respectively. In such examples, the clear boot data 253A may be an entry address for clear boot instructions 253B, the secure boot data 255A may be an entry address for secure boot instructions 255B, and the zeroize boot data 357A may be an entry address for zeroize boot instructions 357B.
  • In the example of FIG. 4A, in response to a reset request 183, vector controller 120 may provide to storage medium 350 a read operation 392 to read from one of a plurality of reset vectors based on state value 181. In some examples, read operation 392 may include a portion of an address on a first bus section 372, read control signal 376, and region selection bits 394. In the examples described above in relation to FIGS. 1-3, reset vector read requests output by vector controller 120 may each be similar to read operation 392.
  • In some examples, interrupt handler 324 may receive reset request 183 and, in response, may provide a memory access address 375 on an address bus 370 of processor 310 as part of a read operation. In some examples, the read operation may be a request to read from a default reset vector of interrupt handler 324, and memory access address 375 may be the address of the default reset vector. The read operation may include memory access address 375 and a read control signal 376 to indicate a read operation to storage medium 350. In some examples, address bus 370 may have first and second bus sections 372 and 374, which may provide first and second portions of an address on address bus 370, respectively, to address selector 326. In such examples, first bus section 372 includes less than all of an address on bus 370, and second bus section 374 includes at least one bit of the address. Address bus 370 may provide the first portion of an address on address bus 370 to storage medium 350 via first bus section 372.
  • In the example of FIG. 4A, address selector 326 may receive memory access address 375 from interrupt handler 324 via address bus 370. In some examples, address selector 326 may receive a first portion of memory access address 375 via first bus section 372 and receive a second portion of address 375 via second bus section 374. In the example of FIG. 4A, region determining module 328 may determine whether memory access address 375 refers to reset region 360 of storage 350. For example, module 328 may determine whether the address 375 is an address within the address range of reset region 360. In some examples, module 328 may determine whether memory access address 375 refers to reset region 360 from the first portion of address 375, received via first bus section 372.
  • In some examples, if module 328 determines from the first portion of address 375 that address 375 refers to reset region 360, then selection bits determining module 329 may set region selection bits 394 based on state value 181. In such examples, address selector 326 may provide the region selection bits 394 to storage medium 350 in place of the second portion of the memory access address output by interrupt handler 324. In this manner, address selector 326 may substitute region selection bits 394 for the second portion of address 372 if address 375 refers to reset region 360, in order to redirect the read request to a reset vector associated with state value 181 (i.e., the operating state of processor 310). If module 328 determines from the first portion of address 375 that address 375 does not refer to reset region 360, then module 329 may set region selection bits 394 equal to the second portion of address 375 received via second bus section 374. In this manner, storage medium 350 may receive the read request output by interrupt hander 324 if address 375 does not refer to reset region 360.
  • In the example of FIG. 4A, if memory access address 375 refers to reset region 360, then region selection bits 394 may distinguish between addresses within reset region 360. For example, region selection bits 394, set based on state value 181, may distinguish among addresses in at least clear region 362, secure region 364, and zeroize region 366. In such examples, the first portion of address 375 together with region selection bits 394, set based on state value 181, may form an address in one of clear region 362, secure region 364, and zeroize region 366. In some examples, the address formed may point to one of a portion of clear boot information 252 stored in clear region 362, a portion of secure boot information 254 stored in secure region 364, and a portion of zeroize boot information 356 stored in zeroize region 366.
  • FIG. 48 is a block diagram of an example address selector 326 to set region selection bits 394 based on a state value 181. The example of FIG. 48 will be described herein in the context of a computing device architecture having a byte-addressed memory and using 32-bit addresses. However, examples described herein may be utilized in the context of other architectures as well. In the example of FIG. 48, address bus 370 may be a 32-bit address bus to communicate a 32-bit address including address bits A0-A31. In some examples, first bus section 372 may communicate address bits A0, A1, and A4-A31, and second bus section 374 may communicate address bits A2 and A3.
  • In some examples, a default reset vector of a processor (e.g., of an interrupt handler of the processor) may be an address pointing to the beginning of a last word (e.g., a last 4 bytes) of addressable memory. For example, the default reset vector may be the hexadecimal address 0xFFFF FFFC, which points to the first of 4 sequentially stored bytes of memory that form the last word of addressable memory. In the example of FIG. 4B, reset region 360 may include hexadecimal addresses 0xFFFF FFF0 through 0xFFFF FFFF, which includes the default reset vector.
  • In some examples, the clear reset vector may be the address 0xFFFF FFFC, the secure reset vector may be the address 0xFFFF FFF8, and the zeroize reset vector may be the address 0xFFFF FFF4. In such examples, reading information from one of these reset vector may include reading 4 sequentially stored bytes beginning at the address of the reset vector. Additionally, in such examples, as the clear reset vector may be the same address as the default reset vector, and the 4 bytes beginning at 0xFFFF FFF0 may be unused.
  • In the example of FIG. 4B, addresses in reset region 360 have the common characteristic that address bits A4-A31 are all logic 1 for addresses in reset region 360. In such examples, region determining module 328 may determine that a memory access address 375 on address bus 370 refers to reset region 360 if each of address bits A4-A31 is a logic 1. In some examples, module 328 may include an AND gate 432 to perform an AND operation on address bits A4-A31 of first bus section 372 to determine whether memory access address 375 refers to reset region 360. In some examples, address bits A4-A31 may be a portion of the first portion of address 375 described above in relation to FIG. 4A. If each of bits A4-A31 is a logic 1, then AND gate 432 may output a logic 1 as region signal 435, indicating that address 375 refers to reset region 360. If any of bits A4-A31 is not a logic 1, then AND gate 432 may output a logic 0 as region signal 435, indicating that address 375 does not refer to reset region 360.
  • In some examples, selection bits determining module 329 may include a multiplexer 438 and two inverters 434 and 436. In such examples, multiplexer 438 may receive region signal 435, address bits A2 and A3 of second bus section 374, and the respective outputs of inverters 434 and 436. Multiplexer 438 may output region selection bits 394. In some examples, multiplexer 438 may set region selection bits 394 based on address bits A2 and A3 if region signal 435 is a logic 0, indicating that address 375 does not refer to reset region 360. In such examples, multiplexer 438 may output address bits A2 and A3 to storage medium 350 (of FIG. 4A) as region selection bits 394, if region signal 435 is a logic 0. In this manner, storage medium 350 receives the original address 375 placed on address bus 370 (e.g., by interrupt handler 324 of FIG. 4A), if address 375 is not within reset region 360.
  • In some examples, multiplexer 438 may set region selection bits 394 based state value 181, if region signal 435 is a logic 1, indicating that memory access address 375 refers to reset region 360. In some examples, state value 181 is stored as one or more bits in state storage 112 (of FIG. 4A), depending upon the number of possible state values. In the example of FIG. 4B, the three possible values of state value 181 (e.g., clear, secure, and zeroize) may be represented by two state bits 481A and 481B stored in state storage 112. In other examples, each state may have its own bit and module 329 may include logic to encode the individual bits into state bits such as state bits 481A and 481B.
  • In the example of FIG. 4B, a state value 181 of “00” may indicate the clear state, with state bits 481B and 481A both being a logic 0. A state value 181 of “01” may indicate the secure state, with state bit 481B being logic 0 and state bit 481A being logic 1, and a state value 181 of “10” may indicate the zeroize state, with state bit 481B being logic 1 and state bit 481A being logic 0. In such examples, inverters 434 and 436 may provide inverted values of state bits 481B and 481A to multiplexer 438. In some examples, if region signal 435 is a logic 1, multiplexer 438 may set region selection bits 394 to be the values output by inverters 434 and 436 to thereby substitute these bits for address bits A3 and A2, respectively.
  • In such examples, when state value 181 indicates the clear state, multiplexer 438 may output “11” as region selection bits 394, to cause vector controller 120 (of FIG. 4A) to read from a clear reset vector, which is address 0xFFFF FFFC. When state value 181 indicates the secure state, multiplexer 438 may output “10” as region selection bits 394, to cause vector controller 120 (of FIG. 4A) to read from a secure reset vector, which is address 0xFFFF FFF8. When state value 181 indicates the zeroize state, multiplexer 438 may output “01” as region selection bits 394, to cause vector controller 120 (of FIG. 4A) to read from a zeroize reset vector, which is address 0xFFFF FFF4.
  • In this manner, address selector 326 may detect a read operation having a read address referring to reset region 360, such as a request to read a default reset vector, and redirect the read request to a state-specific reset vector based on state value 181. Additionally, address selector 326 may allow addresses not referring to reset region 360 to be provided to storage medium 350 (of FIG. 4A) without redirection when the initial read address does not refer to reset region 360. In such examples, a reset vector for a state other than the current state cannot be accessed since address selector 326 may redirect read requests for the reset region to the reset vector of the current state.
  • In the example of FIG. 4B, the assignment of state bits 481A and 481B and the use of inverters 434 and 436 allow the clear state to have a value of “00” while also allowing the clear state reset vector to have the same address as a default reset vector (e.g., 0xFFFF FFFC). However, in other examples, different assignments of state bit values to operating states may be used, and/or inverters 434 and 436 may be omitted.
  • Additionally, in other examples, address selector 326 may be used to substitute region selection bits for different address bits. For example, second bus section 374 may include address bits A12 and A13, while first bus section 372 includes the remaining address bits. In such examples, reset region 360 may be the last 16 kilobytes (KB) of storage medium 350, with each of the three operating states having a full 4 KB block assigned to it (with one 4 KB block being unused). Such examples may be implemented in a manner similar to the example illustrated in FIG. 4B, except that AND gate 432 may perform the AND operation on address bits A14-A31, and region selection bits 394 may be substituted for address bits A12 and A13 to select among the 4 KB blocks of reset region 360. In such examples, reset region 360 may include a 4 KB clear region 362, a 4 KB secure region 352, and a 4 KB zeroize region 366. In such examples, clear region 362 may include up to 4 KB of clear boot information 252, secure region 352 may include up to 4 KB of secure boot information 254, and zeroize region 366 may include up to 4 KB of zeroize boot information 356. In such examples, a 4 KB block for a state other than the current state cannot be accessed since address selector 326 may redirect read requests for the reset region to the 4 KB block of the current state.
  • In other examples, a different computing device architecture may be utilized. For example, examples described herein may be implemented with a word-addressed memory using 20-bit addresses. In such examples, a vector controller may use an address selector similar to address selector 326 of FIG. 4B, except that AND gate 432 may perform the AND operation on address bits A2-A19, and module 329 may substitute region selection bits 394 for address bits A0 and A1.
  • FIG. 5 is a flowchart of an example method 500 for booting a computing device with different boot information based on a state value. Although execution of method 500 is described below with reference to processor 110 of FIG. 1, other suitable components for execution of method 500 can be utilized (e.g., computing device 300). Additionally, method 500 may be implemented by logic on a processor, regardless of how the logic on the processor is implemented.
  • At 505 of method 500, vector controller 120 of processor 110 may receive a state value 181 from state storage 112. In some examples, state value may indicate one of a plurality of operating states of processor 110. For example, the operating states may include a clear state associated with a clear state reset vector pointing to clear boot information, a secure state associated with a secure state reset vector pointing to secure boot information, and a zeroize state associated with a zeroize state reset vector pointing to zeroize boot information. In some examples, the secure boot information may have a different format than the clear boot information, as described above in relation to FIGS. 1-3. Additionally, in some examples, the clear boot information, the secure boot information, and the zeroize boot information may be independent from one another.
  • At 510 of method 500, vector controller 120 may receive reset request 183. In the example of FIG. 5, processor 110 may, in response to reset request 183, boot a computing device including processor 110 based on state value 181 and information stored at a reset vector associated with state value 181. In such examples, in response to reset request 183, processor 110 may determine at 515 whether state value 181 indicates the clear state. If so, method 500 may proceed to 520. If not, processor 110 may determine at 525 whether state value 181 indicates the secure state. If so, method 500 may proceed to 530. If not, processor 110 may determine at 535 whether state value 181 indicates the zeroize state. If so, method 500 may proceed to 540. If not, method 500 may return to 515. In other examples, method 500 may determine which the state indicated by state value 181 in a different order.
  • At 520 of method 500, processor 110 may boot the computing device including processor 110 based on state value 181 indicating the clear state and based on information stored at the reset vector associated with state value 181. As used herein, a given reset vector is “associated with” a given operating state of a processor if the processor is to read from the given reset vector in response to a reset vector when it is in the given operating state. In some examples, processor 110 is to read from a clear state reset vector when state value 181 indicates the clear state. In such examples, at 520, processor 110 may boot the computing device based on a portion of clear boot information (e.g. clear boot data) stored at the clear state reset vector, as described above in relation to FIGS. 1-3. In this manner, processor 110 may boot the computing device based on the clear boot information.
  • At 530 of method 500, processor 110 may boot the computing device based on state value 181 indicating the secure state and based on information stored at a secure state reset vector associated with the secure state value. In such examples, at 530, processor 110 may boot the computing device based on a portion of secure boot information (e.g., secure boot data) stored at the secure state reset vector, as described above in relation to FIGS. 1-3. In this manner, processor 110 may boot the computing device based on the secure boot information. At 540 of method 500, processor 110 may boot the computing device based on state value 181 indicating the zeroize state and based on information stored at a zeroize state reset vector associated with the zeroize state value. In such examples, at 540, processor 110 may boot the computing device based on a portion of zeroize boot information (e.g., zeroize boot data) stored at the zeroize state reset vector, as described above in relation to FIGS. 2-3. In this manner, processor 110 may boot the computing device based on the zeroize boot information.
  • FIG. 6 is a flowchart of an example method 600 for booting a computing device with one of a plurality of sets of boot information stored in different formats based on a state value. Although execution of method 600 is described below with reference to processor 110 of FIG. 1, other suitable components for execution of method 600 can be utilized (e.g., computing device 300). Additionally, method 600 may be implemented by logic on a processor, regardless of how the logic on the processor is implemented.
  • At 605 of method 600, vector controller 120 of processor 110 may receive a state value 181 from state storage 112. In some examples, state value may indicate a clear state associated with a clear state reset vector pointing to clear boot information, a secure state associated with a secure state reset vector pointing to secure boot information, or a zeroize state associated with a zeroize state reset vector pointing to zeroize boot information. In the example of FIG. 6, the clear boot information may be stored in a first format, the secure boot information may be stored in a second format different than the first format, and the zeroize boot information may be stored in a third format different than the first and second formats. In some examples, none of the first, second, and third formats is a format of information that processor 110 may operate on without first reformatting the information. For example, each of the first, second, and third formats may be an encoded or otherwise encrypted format, and not a cleartext format. Additionally, in some examples, the clear boot information, the secure boot information, and the zeroize boot information may be independent from one another.
  • At 610 of method 600, vector controller 120 may receive reset request 183. In the example of FIG. 6, processor 110 may, in response to reset request 183, boot a computing device including processor 110 based on state value 181 and information stored at a reset vector associated with the state value 181. In such examples, in response to reset request 183, processor 110 may determine at 615 whether state value 181 indicates the clear state. If so, method 600 may proceed to 620. If not, processor 110 may determine at 635 whether state value 181 indicates the secure state. If so, method 600 may proceed to 640. If not, processor 110 may determine at 650 whether state value 181 indicates the zeroize state. If so, method 600 may proceed to 655. If not, method 600 may return to 615. In other examples, method 600 may determine which the state indicated by state value 181 in a different order.
  • At 620 of method 600, processor 110 may boot the computing device based on state value 181 indicating the clear state and based on information stored at a clear state reset vector associated with the clear state value. In such examples, at 620, processor 110 may boot the computing device based on a portion of clear boot information (e.g., clear boot data) stored at the clear state reset vector, as described above in relation to FIGS. 1-3. In this manner, processor 110 may boot the computing device with the clear boot information. Additionally, at 620, booting the computing device with the clear boot information may include reformatting the clear boot information from the first format to a cleartext format with, for example, a formatting module of vector controller 120, as described above in relation to FIG. 2. After booting with the clear boot information, method 600 may proceed to 625, where processor 110 may receive a security parameter. After receiving the security parameter, method 600 may proceed to 630, where processor 110 may store the security parameter in a secure parameter storage of processor 110, as described above in relation to FIG. 3.
  • At 640 of method 600, processor 110 may boot the computing device based on state value 181 indicating the secure state and based on information stored at a secure state reset vector associated with the secure state value. In such examples, at 640, processor 110 may boot the computing device based on a portion of secure boot information (e.g., secure boot data) stored at the secure state reset vector, as described above in relation to FIGS. 1-3. In this manner, processor 110 may boot the computing device with the secure boot information. Additionally, at 640, booting the computing device with the secure boot information may include reformatting the secure boot information from the second format to a cleartext format with a formatting module of vector controller 120, as described above in relation to FIG. 2.
  • After booting with the secure boot information, method 600 may proceed to 645, where processor 110 may zeroize the security parameter stored in the secure parameter storage of processor 110 in response to a security incident. In some examples, processor 110 may monitor processor 110 and/or the computing device including processor 110 for security incidents, as described above in relation to FIG. 3. In response to detecting a security incident, processor 110 may zeroize at least one security parameter stored in secure parameter storage of processor 110 at 645.
  • At 655 of method 600, processor 110 may boot the computing device based on state value 181 indicating the zeroize state and based on information stored at a zeroize state reset vector associated with the zeroize state value. In such examples, at 655, processor 110 may boot the computing device based on a portion of zeroize boot information (e.g., zeroize boot data) stored at the zeroize state reset vector, as described above in relation to FIGS. 2-3. In this manner, processor 110 may boot the computing device with the zeroize boot information. Additionally, at 655, booting the computing device with the zeroize boot information may include reformatting the zeroize boot information from the third format to a cleartext format with a formatting module of vector controller 120, as described above in relation to FIG. 2.
  • After booting with the zeroize boot information, method 600 may proceed to 660, where processor 110 may perform at least one fault diagnostic operation. In some examples the operation may be performed to investigate a security incident that caused processor 110 to enter the zeroize state. In such examples, the operation may include analyzing and/or outputting at least one incident record stored in record storage by processor 110 when processor 110 was in the clear or secure state. In some examples, the operation may be implemented in the form of executable instructions encoded on a machine-readable storage medium, in the form of electronic circuitry, or a combination thereof.

Claims (15)

What is claimed is:
1. A processor comprising:
state storage to store a state value indicating an operating state of the processor; and
a vector controller to:
read, from a clear state reset vector, a portion of clear boot information having a first format in response to a reset request, if the state value indicates a clear state; and
read, from a secure state reset vector, a portion of secure boot information having a second format in response to the reset request, if the state value indicates a secure state, wherein the first and second formats are different.
2. The processor of claim 1, wherein the clear boot information includes clear boot instructions of the first format, the secure boot information includes secure boot instructions of the second format, and wherein the vector controller comprises:
a core module to operate on information having the first format; and
a formatting module to:
receive information from a storage medium;
reformat the received information to the first format, if the state value indicates the secure state;
reformat information to be written to the storage medium from the first format to the second format, if the state value indicates the secure state; and
output the received information in the format in which it was received, if the state value indicates the clear state.
3. The processor of claim 2, wherein:
the first format is an unencrypted format;
the second format is an encrypted format; and
the formatting module further comprises:
an encryption module to decrypt the received information, if the state value indicates the secure state.
4. The processor of claim 2, wherein the vector controller is further to:
read, from a zeroize state reset vector, a portion of zeroize boot information in response to the reset request, if the state value indicates a zeroize state, wherein the zeroize boot information includes zeroize boot instructions.
5. The processor of claim 4, wherein:
the zeroize boot information has a third format different from the first and second formats;
the formatting module is further to reformat the received information from the third format to the first format, if the state value indicates the zeroize state; and
the secure boot information includes validation data.
6. A computing device comprising:
a processor comprising:
state storage to store a state value indicating an operating state of the processor; and
a vector controller to:
read, from a clear state reset vector, a portion of clear boot information in response to a reset request, if the state value indicates a clear state;
read, from a secure state reset vector, a portion of secure boot information in response to the reset request, if the state value indicates a secure state; and
read, from a zeroize state reset vector, a portion of zeroize boot information in response to the reset request, if the state value indicates a zeroize state, wherein the clear boot information, the secure boot information, and the zeroize boot information are each independent from one another.
7. The computing device of claim 6, further comprising:
a machine-readable storage medium encoded with instructions executable by the processor, the storage medium comprising the clear boot information including clear boot instructions, the secure boot information including secure boot instructions, and zeroize boot information including zeroize boot instructions; and
wherein the processor further comprises:
a storage control module to:
prevent information from being written to the secure parameter storage, if the state value indicates the zeroize state; and
permit information to be written to the secure parameter storage, if the state value indicates the clear state or the secure state.
8. The computing device of claim 7, wherein the processor further comprises:
a security control module to:
monitor the processor for security incidents;
store an incident record in response to detecting a security incident, if the state value indicates the clear state;
zeroize the secure parameter storage in response to detecting the security incident, if the state value indicates the secure state; and
indicate the occurrence of the security incident in response to detecting the security incident, if the state value indicates the zeroize state.
9. The computing device of claim 6, wherein:
the clear and zeroize boot information has a first format;
the secure boot information has a second format different than the first format; and
the processor comprises a formatting module to reformat the read information from the second format to the first format, if the state value indicates the secure state.
10. The computing device of claim 6, further comprising:
an address bus to:
provide a memory access address having first and second portions to an address selector of the vector controller; and
provide the first portion of the memory access address to the storage medium;
wherein the address selector is to:
receive the memory access address; and
provide, to the storage medium, region selection bits, set based on the state value, as the second portion of the memory access address, if the memory access address refers to a reset region of the storage medium.
11. The computing device of claim 10, wherein:
the vector controller further comprises:
an interrupt handler to provide the memory access address on the address bus as part of a read operation in response to the reset request; and
the address selector comprises:
a region determining module to perform an AND operation on at least a portion of the first portion of the memory access address to determine whether the memory access address refers to the reset region; and
a multiplexer to set the region selection bits based on the state value, if the region determining module indicates that the memory access address refers to the reset region.
12. The computing device of claim 11, wherein:
the reset region of the storage medium comprises a clear region including at least the portion of clear boot information, a secure region including at least the portion of the secure boot information, and a zeroize region including at least the portion of the zeroize boot information; and
wherein the region selection bits distinguish among addresses in at least the clear region, the secure region, and the zeroize region, if the first portion of the memory access address refers to the reset region.
13. A method comprising:
receiving, from state storage, a state value indicating one of a plurality of operating states of a processor, the operating states including a clear state associated with a clear state reset vector pointing to clear boot information, a secure state associated with a secure state reset vector pointing to secure boot information having a different format than the clear boot information, and a zeroize state associated with a zeroize state reset vector pointing to zeroize boot information; and
booting, in response to a reset request, a computing device including the processor with the clear, secure, or zeroize boot information based on the state value and information stored at the reset vector associated with the state value, wherein the clear boot information, the secure boot information, and the zeroize boot information are independent from one another.
14. The method of claim 13, further comprising:
receiving a security parameter with the processor, if the computing device is booted with the clear boot information;
storing the received security parameter in parameter storage of the processor, if the computing device is booted with the clear boot information;
zeroizing the security parameter in the parameter storage in response to a security incident, if the computing device is booted with the secure boot information;
performing a fault diagnostic operation, if the computing device is booted with the zeroize boot information.
15. The method of claim 13, wherein:
booting the computing device with the clear boot information comprises reformatting the clear boot information from a first format to a cleartext format;
booting the computing device with the secure boot instructions comprises reformatting the secure boot information from a second format to a cleartext format, wherein the first and second formats are different; and
booting the computing device with the zeroize boot information comprises reformatting the zeroize boot information from a third format to a cleartext format, wherein the third format is different than the first and second formats.
US14/233,310 2011-07-18 2011-12-15 Reset vectors for boot instructions Abandoned US20140149729A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/233,310 US20140149729A1 (en) 2011-07-18 2011-12-15 Reset vectors for boot instructions

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161509078P 2011-07-18 2011-07-18
US14/233,310 US20140149729A1 (en) 2011-07-18 2011-12-15 Reset vectors for boot instructions
PCT/US2011/065081 WO2013012436A1 (en) 2011-07-18 2011-12-15 Reset vectors for boot instructions

Publications (1)

Publication Number Publication Date
US20140149729A1 true US20140149729A1 (en) 2014-05-29

Family

ID=47422868

Family Applications (12)

Application Number Title Priority Date Filing Date
US14/233,321 Active US9465755B2 (en) 2011-07-18 2011-12-15 Security parameter zeroization
US14/233,310 Abandoned US20140149729A1 (en) 2011-07-18 2011-12-15 Reset vectors for boot instructions
US14/232,217 Abandoned US20140164793A1 (en) 2011-07-18 2011-12-22 Cryptographic information association to memory regions
US14/232,229 Abandoned US20140140512A1 (en) 2011-06-18 2012-01-06 Requested and allowed cryptographic operations comparison
US13/355,315 Active 2033-04-20 US8930154B2 (en) 2011-07-18 2012-01-20 First and second voltage measurements to adjust a voltage measurer
US14/232,224 Active US9483422B2 (en) 2011-07-18 2012-01-31 Access to memory region including confidential information
US14/131,291 Abandoned US20140223113A1 (en) 2011-07-18 2012-02-03 Selector syncronized with movement of data in memory
US14/130,871 Expired - Fee Related US9418026B2 (en) 2011-07-18 2012-02-08 Transition between states in a processor
US13/407,845 Active 2033-10-14 US9015516B2 (en) 2011-07-18 2012-02-29 Storing event data and a time value in memory with an event logging module
US14/233,334 Expired - Fee Related US9418027B2 (en) 2011-07-18 2012-03-30 Secure boot information with validation control data specifying a validation technique
US13/455,867 Abandoned US20130024153A1 (en) 2011-07-18 2012-04-25 Microprocessor testing circuit
US13/459,523 Abandoned US20130024637A1 (en) 2011-07-18 2012-04-30 Memory access unlock

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US14/233,321 Active US9465755B2 (en) 2011-07-18 2011-12-15 Security parameter zeroization

Family Applications After (10)

Application Number Title Priority Date Filing Date
US14/232,217 Abandoned US20140164793A1 (en) 2011-07-18 2011-12-22 Cryptographic information association to memory regions
US14/232,229 Abandoned US20140140512A1 (en) 2011-06-18 2012-01-06 Requested and allowed cryptographic operations comparison
US13/355,315 Active 2033-04-20 US8930154B2 (en) 2011-07-18 2012-01-20 First and second voltage measurements to adjust a voltage measurer
US14/232,224 Active US9483422B2 (en) 2011-07-18 2012-01-31 Access to memory region including confidential information
US14/131,291 Abandoned US20140223113A1 (en) 2011-07-18 2012-02-03 Selector syncronized with movement of data in memory
US14/130,871 Expired - Fee Related US9418026B2 (en) 2011-07-18 2012-02-08 Transition between states in a processor
US13/407,845 Active 2033-10-14 US9015516B2 (en) 2011-07-18 2012-02-29 Storing event data and a time value in memory with an event logging module
US14/233,334 Expired - Fee Related US9418027B2 (en) 2011-07-18 2012-03-30 Secure boot information with validation control data specifying a validation technique
US13/455,867 Abandoned US20130024153A1 (en) 2011-07-18 2012-04-25 Microprocessor testing circuit
US13/459,523 Abandoned US20130024637A1 (en) 2011-07-18 2012-04-30 Memory access unlock

Country Status (4)

Country Link
US (12) US9465755B2 (en)
EP (3) EP2734951A4 (en)
CN (3) CN103688269A (en)
WO (8) WO2013012436A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140189340A1 (en) * 2011-07-18 2014-07-03 Ted A. Hadley Secure boot information with validation control data specifying a validation technique
US20160156469A1 (en) * 2013-05-08 2016-06-02 Cyber Solutions Internationa, LLC Trusted tamper reactive secure storage
US20180275731A1 (en) * 2017-03-21 2018-09-27 Hewlett Packard Enterprise Development Lp Processor reset vectors
US11184159B1 (en) * 2020-09-01 2021-11-23 Slack Technologies, Inc. Encryption key management for channels with multiple organizations

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130155081A1 (en) * 2011-12-15 2013-06-20 Ati Technologies Ulc Power management in multiple processor system
US9094830B2 (en) * 2012-07-05 2015-07-28 Blackberry Limited Managing data transfer across a network interface
US9275223B2 (en) * 2012-10-19 2016-03-01 Mcafee, Inc. Real-time module protection
US9575768B1 (en) 2013-01-08 2017-02-21 Marvell International Ltd. Loading boot code from multiple memories
US9529732B2 (en) * 2013-07-24 2016-12-27 Marvell World Trade Llc Key rotation for a memory controller
WO2015015305A1 (en) * 2013-07-31 2015-02-05 Marvell Word Trade Ltd. Parallelizing boot operations
US10235935B2 (en) * 2013-10-30 2019-03-19 Joled Inc. Power off method of display device, and display device
US9253213B2 (en) * 2013-12-16 2016-02-02 International Business Machines Corporation Query flow reconstruction in database activity monitoring systems
US10031863B2 (en) * 2014-01-30 2018-07-24 Hewlett Packard Enterprise Development Lp Access controlled memory region
JP6215446B2 (en) * 2014-03-03 2017-10-18 株式会社日立製作所 Method of displaying material fatigue of machine and apparatus therefor
CN106471766B (en) * 2014-03-31 2019-08-06 爱迪德技术有限公司 Crypto chip and correlation technique
US20150293862A1 (en) * 2014-04-10 2015-10-15 Andes Technology Corporation Hardware configuration apparatus
KR101857902B1 (en) * 2014-04-15 2018-05-14 란티크 베테일리궁스-게엠베하 운트 코 카게 Root of trust
GB201413836D0 (en) 2014-08-05 2014-09-17 Arm Ip Ltd Device security apparatus and methods
GB2529429B (en) * 2014-08-19 2021-07-21 Origami Energy Ltd Power distribution control system
US9835043B2 (en) * 2014-10-01 2017-12-05 United Technologies Corporation Guided binding-resistant actuation apparatus and method
US10275604B2 (en) 2014-10-31 2019-04-30 Hewlett Packard Enterprise Development Lp Security record transfer in a computing system
US10503909B2 (en) 2014-10-31 2019-12-10 Hewlett Packard Enterprise Development Lp System and method for vulnerability remediation verification
WO2016108902A1 (en) 2014-12-31 2016-07-07 Hewlett Packard Enterprise Development Lp Enterprise service bus logging
WO2016118128A1 (en) * 2015-01-22 2016-07-28 Hewlett Packard Enterprise Development Lp Router to send a request from a first subnet to a second subnet
US9772652B2 (en) * 2015-02-23 2017-09-26 Dell Products L.P. Systems and methods for distributing and synchronizing real-time clock
GB2538091B (en) * 2015-05-07 2018-03-14 Advanced Risc Mach Ltd Verifying correct code execution context
US9444822B1 (en) * 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US11503031B1 (en) 2015-05-29 2022-11-15 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US10691476B2 (en) * 2015-06-27 2020-06-23 Mcafee, Llc Protection of sensitive data
GB2540961B (en) * 2015-07-31 2019-09-18 Arm Ip Ltd Controlling configuration data storage
GB2540965B (en) 2015-07-31 2019-01-30 Arm Ip Ltd Secure configuration data storage
WO2017071763A1 (en) * 2015-10-29 2017-05-04 Hewlett-Packard Development Company, L.P. Checking a security value calculated for a part of a program code
US10235297B2 (en) 2015-11-04 2019-03-19 International Business Machines Corporation Mechanism for creating friendly transactions with credentials
US10270773B2 (en) * 2015-11-04 2019-04-23 International Business Machines Corporation Mechanism for creating friendly transactions with credentials
US10185633B2 (en) * 2015-12-15 2019-01-22 Intel Corporation Processor state integrity protection using hash verification
US9685389B1 (en) 2016-02-03 2017-06-20 Taiwan Semiconductor Manufacturing Co., Ltd. Formation of getter layer for memory device
US11734430B2 (en) 2016-04-22 2023-08-22 Hewlett Packard Enterprise Development Lp Configuration of a memory controller for copy-on-write with a resource controller
US10417441B2 (en) * 2016-04-29 2019-09-17 International Business Machines Corporation Effectively validating dynamic database queries through database activity monitoring
FR3052279B1 (en) * 2016-06-03 2019-06-21 Proton World International N.V. AUTHENTICATION OF A CARD WITH NON-CONTACT READING
FR3052280A1 (en) 2016-06-03 2017-12-08 Proton World Int Nv
US11126565B2 (en) * 2016-06-27 2021-09-21 Hewlett Packard Enterprise Development Lp Encrypted memory access using page table attributes
JP6799404B2 (en) * 2016-07-13 2020-12-16 株式会社デンソーテン Information processing device and information processing method
US10664183B1 (en) 2016-07-25 2020-05-26 Oracle International Corporation Method and apparatus for storing memory attributes
US11144634B2 (en) * 2016-09-28 2021-10-12 Nanolock Security Inc. Access control for integrated circuit devices
US10069633B2 (en) * 2016-09-30 2018-09-04 Data I/O Corporation Unified programming environment for programmable devices
US11178160B2 (en) * 2017-04-26 2021-11-16 Splunk Inc. Detecting and mitigating leaked cloud authorization keys
US10909248B2 (en) * 2017-06-29 2021-02-02 Microsoft Technology Licensing, Llc Executing encrypted boot loaders
CN109753821B (en) * 2017-11-01 2022-03-15 瑞昱半导体股份有限公司 Data access device and method
US10318438B1 (en) * 2017-12-07 2019-06-11 Nuvoton Technology Corporation Secure memory access using memory read restriction
EP3514499B1 (en) * 2018-01-23 2020-08-26 Siemens Aktiengesellschaft Verification of sensor data
LU100844B1 (en) * 2018-06-25 2019-12-30 Univ Luxembourg Method for preventing ransomware attacks on computing systems
CN110677250B (en) 2018-07-02 2022-09-02 阿里巴巴集团控股有限公司 Key and certificate distribution method, identity information processing method, device and medium
EP3599737A1 (en) * 2018-07-24 2020-01-29 Gemalto Sa Method to create a primary cryptographic key with owner-defined transformation rules
CN110795774B (en) 2018-08-02 2023-04-11 阿里巴巴集团控股有限公司 Measurement method, device and system based on trusted high-speed encryption card
CN110795742B (en) 2018-08-02 2023-05-02 阿里巴巴集团控股有限公司 Metric processing method, device, storage medium and processor for high-speed cryptographic operation
CN110826113A (en) * 2018-08-09 2020-02-21 深圳市菲德越科技有限公司 Data secure storage method and device
CN110874478B (en) 2018-08-29 2023-05-02 阿里巴巴集团控股有限公司 Key processing method and device, storage medium and processor
JP2020043258A (en) 2018-09-12 2020-03-19 キオクシア株式会社 Semiconductor memory and manufacturing method thereof
US10747909B2 (en) 2018-09-25 2020-08-18 Northrop Grumman Systems Corporation System architecture to mitigate memory imprinting
US10754993B2 (en) 2018-09-25 2020-08-25 Northrop Grumman Systems Corporation Architecture to mitigate configuration memory imprinting in programmable logic
US11599403B2 (en) * 2018-10-03 2023-03-07 SK Hynix Inc. Logging mechanism for memory system
US10984108B2 (en) * 2018-10-05 2021-04-20 International Business Machines Corporation Trusted computing attestation of system validation state
JP7018864B2 (en) * 2018-10-15 2022-02-14 ルネサスエレクトロニクス株式会社 Semiconductor devices and their control methods
US11625459B2 (en) * 2019-02-08 2023-04-11 Raytheon Technologies Corporation Embedded processing system with multi-stage authentication
US11228443B2 (en) * 2019-03-25 2022-01-18 Micron Technology, Inc. Using memory as a block in a block chain
CN110309083B (en) * 2019-06-28 2021-09-07 兆讯恒达科技股份有限公司 Memory data scrambling method
US11169973B2 (en) * 2019-08-23 2021-11-09 International Business Machines Corporation Atomically tracking transactions for auditability and security
DE102019122806A1 (en) * 2019-08-26 2021-03-04 Infineon Technologies Ag Cryptographic device
US20210097184A1 (en) * 2019-09-27 2021-04-01 Advanced Micro Devices, Inc. Secure buffer for bootloader
US11768611B2 (en) 2020-04-02 2023-09-26 Axiado Corporation Secure boot of a processing chip
CN113704144A (en) * 2020-05-22 2021-11-26 澜起科技股份有限公司 Memory controller and method for controlling access to memory module
US11868476B2 (en) * 2020-06-02 2024-01-09 Hypori, Inc. Boot-specific key access in a virtual device platform
CN112631720B (en) * 2020-12-23 2023-05-23 海光信息技术股份有限公司 Memory control method, medium and equipment
US11809334B2 (en) * 2021-01-19 2023-11-07 Cirrus Logic Inc. Integrated circuit with asymmetric access privileges
WO2022157467A1 (en) * 2021-01-19 2022-07-28 Cirrus Logic International Semiconductor Limited Integrated circuit with asymmetric access privileges
US20230161875A1 (en) * 2021-11-19 2023-05-25 Nxp Usa, Inc. Supply voltage proportionality monitoring in a system-on-chip (soc)
US20230350820A1 (en) * 2022-04-28 2023-11-02 Infineon Technologies Ag Systems and methods for concurrent logging and event capture
US20230418590A1 (en) * 2022-06-22 2023-12-28 Hewlett-Packard Development Company, L.P. Instruction updates

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5600576A (en) * 1994-03-11 1997-02-04 Northrop Grumman Corporation Time stress measurement device
US6378072B1 (en) * 1998-02-03 2002-04-23 Compaq Computer Corporation Cryptographic system
US20060059345A1 (en) * 2004-09-10 2006-03-16 International Business Machines Corporation System and method for providing dynamically authorized access to functionality present on an integrated circuit chip
US7185249B2 (en) * 2002-04-30 2007-02-27 Freescale Semiconductor, Inc. Method and apparatus for secure scan testing
US7265611B2 (en) * 2003-02-11 2007-09-04 Nxp B.V. Self zeroing for critical, continuous-time applications
US20070226494A1 (en) * 2006-03-23 2007-09-27 Harris Corporation Computer architecture for an electronic device providing single-level secure access to multi-level secure file system
US20070237332A1 (en) * 2001-11-21 2007-10-11 Silicon Image, Inc. Method and system for encrypting and decrypting data using an external agent
US20080183305A1 (en) * 2007-01-29 2008-07-31 David James Foster Master-Slave Security Devices
US20090262940A1 (en) * 2008-02-29 2009-10-22 Min-Soo Lim Memory controller and memory device including the memory controller
US20090276617A1 (en) * 2008-04-30 2009-11-05 Michael Grell Computer system comprising a secure boot mechanism on the basis of symmetric key encryption
US20100037069A1 (en) * 2008-08-06 2010-02-11 Silver Spring Networks, Inc. Integrated Cryptographic Security Module for a Network Node
US20110185165A1 (en) * 2008-10-10 2011-07-28 Tomoyuki Haga Information processing device, information processing method, information processing program, and integrated circuit
US8819839B2 (en) * 2008-05-24 2014-08-26 Via Technologies, Inc. Microprocessor having a secure execution mode with provisions for monitoring, indicating, and managing security levels

Family Cites Families (183)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3183498A (en) 1961-10-02 1965-05-11 Itt Line-monitor circuit
US4424561A (en) 1980-12-31 1984-01-03 Honeywell Information Systems Inc. Odd/even bank structure for a cache memory
JPH0628885B2 (en) 1986-12-19 1994-04-20 松下電器産業株式会社 Injection molding machine
AU601784B2 (en) 1986-12-18 1990-09-20 Honeywell Bull Inc. Data processing system having a bus command generated by one subsystem on behalf of another subsystem
JPH0628885Y2 (en) 1987-05-26 1994-08-03 松下電工株式会社 Box
US5214760A (en) 1988-08-26 1993-05-25 Tektronix, Inc. Adaptable multiple port data buffer
US5497497A (en) 1989-11-03 1996-03-05 Compaq Computer Corp. Method and apparatus for resetting multiple processors using a common ROM
US5872967A (en) 1989-12-29 1999-02-16 Packard Bell Nec Method for warm boot from reset
US5249286A (en) 1990-05-29 1993-09-28 National Semiconductor Corporation Selectively locking memory locations within a microprocessor's on-chip cache
US5131040A (en) 1991-02-28 1992-07-14 Motorola, Inc. Method for backing up and erasing encryption keys
US6836548B1 (en) 1991-10-29 2004-12-28 The Commonwealth Of Australia Communications security and trusted path method and means
US5389738A (en) 1992-05-04 1995-02-14 Motorola, Inc. Tamperproof arrangement for an integrated circuit device
JPH0628885A (en) * 1992-06-23 1994-02-04 Takayama:Kk Memory device
JPH06236325A (en) 1993-02-08 1994-08-23 Sansei Denshi Japan Kk Data storage device
US5450082A (en) 1993-11-29 1995-09-12 Caterpillar Inc. Single multi-purpose input for different types of sensors with data edge conditioning circuit or ADC to provide digital output
JP2697621B2 (en) 1994-07-29 1998-01-14 日本電気株式会社 Signal cycle detection circuit and signal loss monitoring circuit
JP3565583B2 (en) 1994-08-31 2004-09-15 株式会社日立コミュニケーションテクノロジー Semiconductor file storage device
US6948070B1 (en) 1995-02-13 2005-09-20 Intertrust Technologies Corporation Systems and methods for secure transaction management and electronic rights protection
US5956377A (en) 1996-05-31 1999-09-21 Vtech Communications, Ltd. Method and apparatus for synchronizing frames within a continuous stream of digital data
SE516581C2 (en) 1996-05-31 2002-01-29 Totalfoersvarets Forskningsins Auto-calibrating analog-to-digital converter and sensor device including such
US5682328A (en) 1996-09-11 1997-10-28 Bbn Corporation Centralized computer event data logging system
US5825878A (en) 1996-09-20 1998-10-20 Vlsi Technology, Inc. Secure memory management unit for microprocessor
US5937063A (en) 1996-09-30 1999-08-10 Intel Corporation Secure boot
US6047376A (en) 1996-10-18 2000-04-04 Toshiba Information Systems (Japan) Corporation Client-server system, server access authentication method, memory medium stores server-access authentication programs, and issuance device which issues the memory medium contents
US6377691B1 (en) 1996-12-09 2002-04-23 Microsoft Corporation Challenge-response authentication and key exchange for a connectionless security protocol
US7580919B1 (en) 1997-03-10 2009-08-25 Sonicwall, Inc. Query interface to policy server
JPH10333898A (en) * 1997-05-29 1998-12-18 Nec Corp Microcomputer
US5987557A (en) * 1997-06-19 1999-11-16 Sun Microsystems, Inc. Method and apparatus for implementing hardware protection domains in a system with no memory management unit (MMU)
US6161180A (en) * 1997-08-29 2000-12-12 International Business Machines Corporation Authentication for secure devices with limited cryptography
US6694460B2 (en) 1997-09-11 2004-02-17 Renesas Technology Corporation Semiconductor memory device having deterioration determining function
JP3204379B2 (en) 1997-09-29 2001-09-04 エヌイーシーマイクロシステム株式会社 Nonvolatile semiconductor memory device
US6078873A (en) 1997-10-02 2000-06-20 Cummins Engine Company, Inc. Method and apparatus for real-time data stamping via datalink and volatile ECM timer/clock
US6003117A (en) 1997-10-08 1999-12-14 Vlsi Technology, Inc. Secure memory management unit which utilizes a system processor to perform page swapping
IES980710A2 (en) 1997-12-15 1999-06-30 Tellabs Res Ltd Memory Addressing
US6292898B1 (en) 1998-02-04 2001-09-18 Spyrus, Inc. Active erasure of electronically stored data upon tamper detection
DE19824362A1 (en) 1998-05-30 1999-12-16 Micronas Intermetall Gmbh Process for monitoring the function of a sensor module and sensor module for carrying out the process
JP2000200218A (en) 1998-09-01 2000-07-18 Texas Instr Inc <Ti> Microprocessor with cache memory
US6463535B1 (en) * 1998-10-05 2002-10-08 Intel Corporation System and method for verifying the integrity and authorization of software before execution in a local platform
US6553496B1 (en) * 1999-02-01 2003-04-22 Koninklijke Philips Electronics N.V. Integration of security modules on an integrated circuit
US6745306B1 (en) * 1999-07-29 2004-06-01 Microsoft Corporation Method and system for restricting the load of physical address translations of virtual addresses
US6289455B1 (en) 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
WO2001029776A1 (en) 1999-10-18 2001-04-26 Stamps.Com Cryptographic module for secure processing of value-bearing items
US6928551B1 (en) 1999-10-29 2005-08-09 Lockheed Martin Corporation Method and apparatus for selectively denying access to encoded data
US6625727B1 (en) 1999-11-23 2003-09-23 Motorola, Inc. Apparatus and method for configuring a data processing system by retrieving a configuration value from storage device using reset vector and configuring parameters after reset
US6704865B1 (en) 1999-12-23 2004-03-09 Delphi Technologies, Inc. Microprocessor conditional deterministic reset vector method
US6512289B1 (en) 2000-05-09 2003-01-28 Xilinx, Inc. Direct current regulation on integrated circuits under high current design conditions
US6789182B1 (en) 2000-11-13 2004-09-07 Kevin Jay Brothers System and method for logging computer event data and physical components of a complex distributed system
US6938164B1 (en) 2000-11-22 2005-08-30 Microsoft Corporation Method and system for allowing code to be securely initialized in a computer
JP4074057B2 (en) 2000-12-28 2008-04-09 株式会社東芝 Method for sharing encrypted data area among tamper resistant processors
US6859876B2 (en) 2000-12-29 2005-02-22 Hewlett-Packard Development Company, L.P. System and method for detecting and using a replacement boot block during initialization by an original boot block
US20040088333A1 (en) 2002-01-25 2004-05-06 David Sidman Apparatus method and system for tracking information access
GB2372597B (en) 2001-02-27 2005-08-10 Hewlett Packard Co Device and method for data timestamping
JP2002269065A (en) 2001-03-08 2002-09-20 Mitsubishi Electric Corp Microcomputer with incorporated programmable nonvolatile memory
US6466048B1 (en) 2001-05-23 2002-10-15 Mosaid Technologies, Inc. Method and apparatus for switchably selecting an integrated circuit operating mode
US7237121B2 (en) 2001-09-17 2007-06-26 Texas Instruments Incorporated Secure bootloader for securing digital devices
EP1428102A4 (en) 2001-09-06 2009-08-26 Mastercard International Inc Method and device for control by consumers over personal data
JP2003167649A (en) 2001-11-28 2003-06-13 Mitsubishi Electric Corp Information processor
US7065651B2 (en) 2002-01-16 2006-06-20 Microsoft Corporation Secure video card methods and systems
US7107459B2 (en) 2002-01-16 2006-09-12 Sun Microsystems, Inc. Secure CPU and memory management unit with cryptographic extensions
JP2003240810A (en) 2002-02-14 2003-08-27 Mitsubishi Electric Corp Break detection circuit
US7089419B2 (en) 2002-04-18 2006-08-08 International Business Machines Corporation Control function with multiple security states for facilitating secure operation of an integrated system
US7603551B2 (en) 2003-04-18 2009-10-13 Advanced Micro Devices, Inc. Initialization of a computer system including a secure execution mode-capable processor
US6715085B2 (en) 2002-04-18 2004-03-30 International Business Machines Corporation Initializing, maintaining, updating and recovering secure operation within an integrated system employing a data access control function
US6724342B2 (en) 2002-04-19 2004-04-20 Sirf Technology, Inc. Compensation for frequency adjustment in mobile communication-positioning device with shared oscillator
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US20040054859A1 (en) * 2002-09-13 2004-03-18 Chanson Lin Mouse device capable of storing data
US7761904B2 (en) * 2002-09-30 2010-07-20 Harris Corporation Removable cryptographic ignition key system and method
RU2005115094A (en) 2002-11-18 2006-01-20 Арм Лимитед (Gb) DISPLAYING VIRTUAL MEMORY ADDRESSES TO PHYSICAL ADDRESSES IN A SYSTEM WITH A PROTECTED DOMAIN AND AN UNsecure DOMAIN
AU2003278350A1 (en) 2002-11-18 2004-06-15 Arm Limited Secure memory for protecting against malicious programs
GB2396712B (en) 2002-11-18 2005-12-07 Advanced Risc Mach Ltd Handling multiple interrupts in a data processing system utilising multiple operating systems
GB0229759D0 (en) 2002-12-20 2003-01-29 Becrypt Ltd Security device
FR2849233B1 (en) * 2002-12-24 2005-05-20 Trusted Logic METHOD FOR SECURING COMPUTER SYSTEMS BY SOFTWARE CONFINEMENT
US7423529B2 (en) 2003-01-16 2008-09-09 Obs, Inc. Systems and methods for mobile security and monitoring
JP3880933B2 (en) 2003-01-21 2007-02-14 株式会社東芝 Data access control method using tamper resistant microprocessor and cache memory processor
JP4082261B2 (en) 2003-03-31 2008-04-30 株式会社デンソー Disconnection detection circuit for sensor device
JP2004326671A (en) * 2003-04-28 2004-11-18 National Institute Of Advanced Industrial & Technology Remote calibration system for metering instrument and remote calibration method for metering instrument
US20040267847A1 (en) * 2003-05-13 2004-12-30 Bsi2000, Inc. Hardware random-number generator
US7360073B1 (en) 2003-05-15 2008-04-15 Pointsec Mobile Technologies, Llc Method and apparatus for providing a secure boot for a computer system
CN100363855C (en) 2003-07-04 2008-01-23 诺基亚有限公司 Key storage administration
EP2570918A1 (en) 2003-07-07 2013-03-20 Rovi Solutions Corporation Reprogrammable security for controlling piracy and enabling interactive content
US20050091554A1 (en) 2003-08-07 2005-04-28 Dmitrii Loukianov Event time-stamping
US7062615B2 (en) 2003-08-29 2006-06-13 Emulex Design & Manufacturing Corporation Multi-channel memory access arbitration method and system
KR101044937B1 (en) 2003-12-01 2011-06-28 삼성전자주식회사 Home network system and method thereof
US8504798B2 (en) 2003-12-30 2013-08-06 Sandisk Technologies Inc. Management of non-volatile memory systems having large erase blocks
US7299347B1 (en) * 2004-04-02 2007-11-20 Super Talent Electronics, Inc. Boot management in computer systems assisted by an endpoint with PCI-XP or USB-V2 interface
DE102004024002B4 (en) 2004-05-14 2008-05-21 Aim Infrarot-Module Gmbh Method for authenticating sensor data and associated sensor
US7222053B2 (en) 2004-07-12 2007-05-22 Mack Trucks, Inc. Event-driven portable data bus message logger
US8656185B2 (en) 2004-07-30 2014-02-18 Safenet, Inc. High-assurance processor active memory content protection
US7890769B2 (en) 2004-08-04 2011-02-15 Broadcom Corporation System and method for secure code downloading
US20060095726A1 (en) 2004-08-31 2006-05-04 Ivivity, Inc. Independent hardware based code locator
US20060059368A1 (en) * 2004-09-10 2006-03-16 International Business Machines Corporation System and method for processing by distinct entities securely configurable circuit chips
US20060059373A1 (en) 2004-09-10 2006-03-16 International Business Machines Corporation Integrated circuit chip for encryption and decryption using instructions supplied through a secure interface
US7237094B2 (en) 2004-10-14 2007-06-26 International Business Machines Corporation Instruction group formation and mechanism for SMT dispatch
US8332653B2 (en) 2004-10-22 2012-12-11 Broadcom Corporation Secure processing environment
US8621597B1 (en) * 2004-10-22 2013-12-31 Xilinx, Inc. Apparatus and method for automatic self-erasing of programmable logic devices
US7774619B2 (en) 2004-11-17 2010-08-10 Broadcom Corporation Secure code execution using external memory
US7457960B2 (en) 2004-11-30 2008-11-25 Analog Devices, Inc. Programmable processor supporting secure mode
KR100654446B1 (en) 2004-12-09 2006-12-06 삼성전자주식회사 Apparatus and method for Secure booting
US8601283B2 (en) * 2004-12-21 2013-12-03 Sandisk Technologies Inc. Method for versatile content control with partitioning
JP4857283B2 (en) 2004-12-21 2012-01-18 サンディスク コーポレーション Multipurpose content control by partitioning
US7725703B2 (en) * 2005-01-07 2010-05-25 Microsoft Corporation Systems and methods for securely booting a computer with a trusted processing module
US8276185B2 (en) 2005-01-19 2012-09-25 Micron Technology, Inc. Enhanced security memory access method and architecture
JP4522372B2 (en) 2005-02-07 2010-08-11 株式会社ソニー・コンピュータエンタテインメント Method and apparatus for implementing a secure session between a processor and an external device
JP4489030B2 (en) 2005-02-07 2010-06-23 株式会社ソニー・コンピュータエンタテインメント Method and apparatus for providing a secure boot sequence within a processor
US20060184791A1 (en) 2005-02-14 2006-08-17 Schain Mariano R Encryption/decryption mechanism of network deployed executable image for secure boot of a device embedded in an un-trusted host
WO2007142615A2 (en) 2005-02-18 2007-12-13 Credant Technologies, Inc. System and method for intelligence based security
US7321314B2 (en) 2005-03-09 2008-01-22 Intel Corporation Device, system and method of detection of input unit disconnection
US20060215437A1 (en) 2005-03-28 2006-09-28 Trika Sanjeev N Recovering from memory imprints
FR2883998A1 (en) 2005-04-05 2006-10-06 St Microelectronics Sa Coprocessor`s control execution securing method for e.g. microcontroller, involves placing coprocessor in default error mode from commencement of execution of control accomplished by coprocessor
US7571475B2 (en) * 2005-04-05 2009-08-04 Cisco Technology, Inc. Method and electronic device for triggering zeroization in an electronic device
US7336212B2 (en) * 2005-05-02 2008-02-26 Ati Technologies Inc. Apparatus and methods for measurement of analog voltages in an integrated circuit
US7549064B2 (en) 2005-05-10 2009-06-16 Hewlett-Packard Development Company, L.P. Secure circuit assembly
US7793067B2 (en) * 2005-08-12 2010-09-07 Globalfoundries Inc. Translation data prefetch in an IOMMU
US20070067644A1 (en) 2005-08-26 2007-03-22 International Business Machines Corporation Memory control unit implementing a rotating-key encryption algorithm
EP1762855B1 (en) 2005-09-09 2008-12-24 Infineon Technologies AG JTAG port
US7218567B1 (en) * 2005-09-23 2007-05-15 Xilinx, Inc. Method and apparatus for the protection of sensitive data within an integrated circuit
US7496727B1 (en) 2005-12-06 2009-02-24 Transmeta Corporation Secure memory access system and method
JP4643427B2 (en) 2005-12-08 2011-03-02 株式会社日立製作所 Storage system with built-in encryption function
US7657754B2 (en) * 2005-12-08 2010-02-02 Agere Systems Inc Methods and apparatus for the secure handling of data in a microcontroller
US8001374B2 (en) 2005-12-16 2011-08-16 Lsi Corporation Memory encryption for digital video
US7379325B1 (en) 2005-12-16 2008-05-27 Maxim Intergrated Products, Inc. Non-imprinting memory with high speed erase
US7398441B1 (en) 2005-12-21 2008-07-08 Rockwell Collins, Inc. System and method for providing secure boundary scan interface access
US20070237325A1 (en) 2006-02-01 2007-10-11 Gershowitz Michael N Method and apparatus to improve security of cryptographic systems
US7792302B2 (en) 2006-02-01 2010-09-07 Dolby Laboratories Licensing Corporation Securely coupling an FPGA to a security IC
US8291226B2 (en) 2006-02-10 2012-10-16 Qualcomm Incorporated Method and apparatus for securely booting from an external storage device
US7512719B1 (en) 2006-03-16 2009-03-31 American Megatrends, Inc. Sharing a dynamically located memory block between components executing in different processor modes in an extensible firmware interface environment
EP1845470B1 (en) 2006-04-13 2016-11-09 STMicroelectronics (Research & Development) Limited Multiple purpose integrated circuit
US20070288740A1 (en) 2006-06-09 2007-12-13 Dale Jason N System and method for secure boot across a plurality of processors
US7424398B2 (en) 2006-06-22 2008-09-09 Lexmark International, Inc. Boot validation system and method
US7757098B2 (en) 2006-06-27 2010-07-13 Intel Corporation Method and apparatus for verifying authenticity of initial boot code
US8560863B2 (en) 2006-06-27 2013-10-15 Intel Corporation Systems and techniques for datapath security in a system-on-a-chip device
US7886355B2 (en) * 2006-06-30 2011-02-08 Motorola Mobility, Inc. Subsidy lock enabled handset device with asymmetric verification unlocking control and method thereof
GB2439968B (en) 2006-07-07 2011-05-25 Advanced Risc Mach Ltd Memory testing
US7475226B2 (en) 2006-09-20 2009-01-06 International Business Machines Corporation System for managing data dependency using bit field instruction destination vector identifying destination for execution results
US8732854B2 (en) 2006-11-01 2014-05-20 Time Warner Cable Enterprises Llc Methods and apparatus for premises content distribution
US7414553B1 (en) 2006-11-17 2008-08-19 Zilog, Inc. Microcontroller having in-situ autocalibrated integrating analog-to-digital converter (IADC)
US20080162848A1 (en) 2006-12-30 2008-07-03 Hewlett-Packard Development Company, L.P. Controlling access to a memory region
US8254568B2 (en) 2007-01-07 2012-08-28 Apple Inc. Secure booting a computing device
US8725974B2 (en) 2007-01-17 2014-05-13 Oracle America, Inc. Page-protection based memory access barrier traps
US8615665B2 (en) 2007-01-26 2013-12-24 Harris Corporation Method for providing high assurance integrity of installed software images in a software defined radio
JP2008192036A (en) 2007-02-07 2008-08-21 Renesas Technology Corp Microcontroller
JP4933946B2 (en) 2007-04-18 2012-05-16 株式会社日立製作所 External storage device and information leakage prevention method
KR101058140B1 (en) 2007-05-11 2011-08-24 나그라스타 엘.엘.씨. Device for controlling processor execution in a secure environment
JP2008310270A (en) * 2007-06-18 2008-12-25 Panasonic Corp Cryptographic equipment and cryptography operation method
US20090031135A1 (en) 2007-07-27 2009-01-29 Raghunathan Kothandaraman Tamper Proof Seal For An Electronic Document
US7895426B2 (en) 2007-08-24 2011-02-22 International Business Machines Corporation Secure power-on reset engine
US7937596B2 (en) 2007-08-30 2011-05-03 Harris Corporation Adaptable microcontroller based security monitor
JP4993733B2 (en) 2007-09-28 2012-08-08 東芝ソリューション株式会社 Cryptographic client device, cryptographic package distribution system, cryptographic container distribution system, and cryptographic management server device
US8082439B2 (en) 2007-12-06 2011-12-20 Hewlett-Packard Development Company, L.P. Firmware modification in a computer system environment supporting operational state changes
EP2232759B1 (en) 2007-12-13 2018-08-15 Symantec Corporation Apparatus and method for facilitating cryptographic key management services
US7729156B2 (en) 2007-12-26 2010-06-01 Texas Instruments Incorporated Cycling to mitigate imprint in ferroelectric memories
US7667997B2 (en) 2007-12-27 2010-02-23 Texas Instruments Incorporated Method to improve ferroelectronic memory performance and reliability
US8495438B2 (en) 2007-12-28 2013-07-23 Texas Instruments Incorporated Technique for memory imprint reliability improvement
US8175276B2 (en) 2008-02-04 2012-05-08 Freescale Semiconductor, Inc. Encryption apparatus with diverse key retention schemes
US9613215B2 (en) 2008-04-10 2017-04-04 Nvidia Corporation Method and system for implementing a secure chain of trust
US8838924B2 (en) 2008-05-24 2014-09-16 Via Technologies, Inc. Microprocessor having internal secure memory
US7958130B2 (en) * 2008-05-26 2011-06-07 Microsoft Corporation Similarity-based content sampling and relevance feedback
CN101620466A (en) * 2008-06-30 2010-01-06 鸿富锦精密工业(深圳)有限公司 Password protection system and method and password generation device
US8051467B2 (en) 2008-08-26 2011-11-01 Atmel Corporation Secure information processing
US8452984B2 (en) * 2008-08-28 2013-05-28 Alcatel Lucent Message authentication code pre-computation with applications to secure memory
US20100064125A1 (en) 2008-09-11 2010-03-11 Mediatek Inc. Programmable device and booting method
US10802990B2 (en) 2008-10-06 2020-10-13 International Business Machines Corporation Hardware based mandatory access control
CN101478538B (en) 2008-12-31 2012-06-06 成都市华为赛门铁克科技有限公司 Storage method, apparatus or system for safety management device
US7949912B1 (en) 2009-01-15 2011-05-24 Xilinx, Inc. System and method of securing data stored in a memory
US20100268942A1 (en) 2009-04-15 2010-10-21 Secuware Systems and Methods for Using Cryptographic Keys
JP2010282352A (en) 2009-06-03 2010-12-16 Renesas Electronics Corp Dma transfer control device
US8970344B2 (en) 2009-07-14 2015-03-03 Compx International Inc. Method and system for data control in electronic locks
US8644622B2 (en) * 2009-07-30 2014-02-04 Xerox Corporation Compact signature for unordered vector sets with application to image retrieval
CN101995301B (en) 2009-08-20 2012-08-01 上海华虹Nec电子有限公司 Temperature detection circuit of integrated circuit and calibration method thereof
JP5662092B2 (en) 2009-10-27 2015-01-28 株式会社ソニー・コンピュータエンタテインメント Electronic parts and inspection system
WO2011058533A2 (en) 2009-11-16 2011-05-19 Discretix Technologies Ltd. Methods circuits devices and systems for provisioning of cryptographic data to one or more electronic devices
US20110154501A1 (en) 2009-12-23 2011-06-23 Banginwar Rajesh P Hardware attestation techniques
WO2011080841A1 (en) 2009-12-28 2011-07-07 富士通株式会社 Power-source control device and power-source control method
KR20130020734A (en) * 2010-04-12 2013-02-27 인터디지탈 패튼 홀딩스, 인크 Staged control release in boot process
US20120185636A1 (en) * 2010-08-04 2012-07-19 Isc8, Inc. Tamper-Resistant Memory Device With Variable Data Transmission Rate
US9030953B2 (en) 2011-03-04 2015-05-12 Alcatel Lucent System and method providing resilient data transmission via spectral fragments
US8667244B2 (en) 2011-03-21 2014-03-04 Hewlett-Packard Development Company, L.P. Methods, systems, and apparatus to prevent memory imprinting
WO2013012436A1 (en) 2011-07-18 2013-01-24 Hewlett-Packard Development Company, L.P. Reset vectors for boot instructions
US8527675B2 (en) 2011-07-27 2013-09-03 Raytheon Company System and method for implementing a secure processor data bus
WO2013016643A2 (en) 2011-07-28 2013-01-31 Integrated Technology Corporation Damage reduction method and apparatus for destructive testing of power semiconductors
EP2665032A1 (en) 2012-05-14 2013-11-20 Thomson Licensing Methods and devices for 3d object protection using surface subdivision
US8572410B1 (en) * 2012-07-18 2013-10-29 Freescale Semiconductor, Inc. Virtualized protected storage
EP2808804A1 (en) 2013-05-29 2014-12-03 Fujitsu Ltd. Database controller, method, and program for handling range queries

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5600576A (en) * 1994-03-11 1997-02-04 Northrop Grumman Corporation Time stress measurement device
US6378072B1 (en) * 1998-02-03 2002-04-23 Compaq Computer Corporation Cryptographic system
US20070237332A1 (en) * 2001-11-21 2007-10-11 Silicon Image, Inc. Method and system for encrypting and decrypting data using an external agent
US7185249B2 (en) * 2002-04-30 2007-02-27 Freescale Semiconductor, Inc. Method and apparatus for secure scan testing
US7265611B2 (en) * 2003-02-11 2007-09-04 Nxp B.V. Self zeroing for critical, continuous-time applications
US20060059345A1 (en) * 2004-09-10 2006-03-16 International Business Machines Corporation System and method for providing dynamically authorized access to functionality present on an integrated circuit chip
US20070226494A1 (en) * 2006-03-23 2007-09-27 Harris Corporation Computer architecture for an electronic device providing single-level secure access to multi-level secure file system
US20080183305A1 (en) * 2007-01-29 2008-07-31 David James Foster Master-Slave Security Devices
US20090262940A1 (en) * 2008-02-29 2009-10-22 Min-Soo Lim Memory controller and memory device including the memory controller
US20090276617A1 (en) * 2008-04-30 2009-11-05 Michael Grell Computer system comprising a secure boot mechanism on the basis of symmetric key encryption
US8819839B2 (en) * 2008-05-24 2014-08-26 Via Technologies, Inc. Microprocessor having a secure execution mode with provisions for monitoring, indicating, and managing security levels
US20100037069A1 (en) * 2008-08-06 2010-02-11 Silver Spring Networks, Inc. Integrated Cryptographic Security Module for a Network Node
US20110185165A1 (en) * 2008-10-10 2011-07-28 Tomoyuki Haga Information processing device, information processing method, information processing program, and integrated circuit

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140189340A1 (en) * 2011-07-18 2014-07-03 Ted A. Hadley Secure boot information with validation control data specifying a validation technique
US9015516B2 (en) 2011-07-18 2015-04-21 Hewlett-Packard Development Company, L.P. Storing event data and a time value in memory with an event logging module
US9418027B2 (en) * 2011-07-18 2016-08-16 Hewlett Packard Enterprise Development Lp Secure boot information with validation control data specifying a validation technique
US9465755B2 (en) 2011-07-18 2016-10-11 Hewlett Packard Enterprise Development Lp Security parameter zeroization
US20160156469A1 (en) * 2013-05-08 2016-06-02 Cyber Solutions Internationa, LLC Trusted tamper reactive secure storage
US9641330B2 (en) * 2013-05-08 2017-05-02 Cyber Solutions International, Llc Trusted tamper reactive secure storage
US20180275731A1 (en) * 2017-03-21 2018-09-27 Hewlett Packard Enterprise Development Lp Processor reset vectors
US11184159B1 (en) * 2020-09-01 2021-11-23 Slack Technologies, Inc. Encryption key management for channels with multiple organizations
US20220158830A1 (en) * 2020-09-01 2022-05-19 Slack Technologies, Llc Encryption key management for channels with multiple organizations
US11818250B2 (en) * 2020-09-01 2023-11-14 Salesforce, Inc. Encryption key management for channels with multiple organizations

Also Published As

Publication number Publication date
US9418027B2 (en) 2016-08-16
WO2013012437A1 (en) 2013-01-24
US20130024716A1 (en) 2013-01-24
US20140189340A1 (en) 2014-07-03
WO2013012449A1 (en) 2013-01-24
US9015516B2 (en) 2015-04-21
EP2735000A4 (en) 2015-03-11
US9465755B2 (en) 2016-10-11
EP2734951A1 (en) 2014-05-28
US20130024143A1 (en) 2013-01-24
US20140156961A1 (en) 2014-06-05
EP2735000A1 (en) 2014-05-28
WO2013012447A1 (en) 2013-01-24
EP2734951A4 (en) 2015-05-20
WO2013012461A1 (en) 2013-01-24
EP2734903A1 (en) 2014-05-28
US20140165206A1 (en) 2014-06-12
EP2734903B1 (en) 2018-10-10
US20140164793A1 (en) 2014-06-12
US8930154B2 (en) 2015-01-06
US20140130189A1 (en) 2014-05-08
WO2013012436A1 (en) 2013-01-24
US20140223113A1 (en) 2014-08-07
US9418026B2 (en) 2016-08-16
CN103688269A (en) 2014-03-26
US20140140512A1 (en) 2014-05-22
US20130024153A1 (en) 2013-01-24
WO2012177295A1 (en) 2012-12-27
CN103890852A (en) 2014-06-25
WO2013012444A1 (en) 2013-01-24
CN103733204A (en) 2014-04-16
US9483422B2 (en) 2016-11-01
WO2013012435A1 (en) 2013-01-24
US20130024637A1 (en) 2013-01-24
EP2734903A4 (en) 2016-03-02

Similar Documents

Publication Publication Date Title
US20140149729A1 (en) Reset vectors for boot instructions
US11777705B2 (en) Techniques for preventing memory timing attacks
US20170288869A1 (en) Secure key storage using physically unclonable functions
US8423788B2 (en) Secure memory card with life cycle phases
TWI436372B (en) Flash memory storage system, and controller and method for anti-falsifying data thereof
US8583880B2 (en) Method for secure data reading and data handling system
US20080034350A1 (en) System and Method for Checking the Integrity of Computer Program Code
US11281807B2 (en) Processing system, related integrated circuit and method
KR20200051694A (en) Call path dependent authentication
EP1638033A2 (en) Self testing and securing RAM system and method
US20130013934A1 (en) Infinite Key Memory Transaction Unit
KR20180059954A (en) Memory integrity
CN103778075A (en) Security management unit, host controller interface including same, method operating host controller interface
US8751817B2 (en) Data processing apparatus and validity verification method
US9104890B2 (en) Data processing device and a secure memory device including the same
US9842214B2 (en) System and method to secure on-board bus transactions
US20080076355A1 (en) Method for Protecting Security Accounts Manager (SAM) Files Within Windows Operating Systems
KR20210132723A (en) Proof of data in memory
US8458491B1 (en) Cryptographically scrubbable storage device
CN112930659A (en) Method and apparatus for secure key generation
US20140173294A1 (en) Techniques for emulating an eeprom device
KR20210132736A (en) Runtime code execution validity
US20190199735A1 (en) Device and method for verifying integrity of firmware
EP1843250B1 (en) System and method for checking the integrity of computer program code
CN109583197B (en) Trusted overlay file encryption and decryption method

Legal Events

Date Code Title Description
AS Assignment

Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HADLEY, TED A;REEL/FRAME:032432/0851

Effective date: 20111212

AS Assignment

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001

Effective date: 20151027

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE