Protection of customer and internal register data during hardware checkstops in multi-tenant environments

Abstract

A method and corresponding system for encrypting customer workload data through a trusted entity, such as a self-boot engine (SBE), is provided. More particularly, there is a method and corresponding system for securely extracting customer-centric data, in which the scheme requires customer payloads and / or workloads to register with the SBE and share an encryption key.

Description

Technical Field

[0001] The present invention generally relates to the field of data security, and more particularly to the protection of user data collected during data dump processing.

Background Art

[0002] In this document, the terms hardware checkstop (HW checkstop) and machine check exception (MCE) are used interchangeably. The Wikipedia article on "Machine check exception" states (as of April 25, 2021) as follows: "A machine check exception (MCE) is a type of computer hardware error that occurs when a computer's central processing unit detects a hardware error in the processor itself, memory, I / O device, or system bus; depending on the architecture, MCEs occur only for non-recoverable errors. In the x86 architecture, machine check exceptions are not caused by software. However, in other architectures such as PowerPC, certain software bugs such as invalid memory accesses can cause machine check exceptions. This error usually occurs due to component failures or overheating or overclocking of hardware components. In most machine check exceptions, the operating system halts and a reboot is required, after which the user can resume normal work. It can often be difficult to pinpoint the cause of the failure, as little information about the cause of the problem is collected during the error."

Summary of the Invention

[0003] According to one aspect of the present invention, there is a method, computer program product, and / or system that performs the following operations (not necessarily in the following order): (i) a hardware thread on a processor core receives a set of user workload data, which includes confidential secure information (SSI); (ii) extracts the SSI from the processor core to obtain a first extracted SSI; (iii) registers the first extracted SSI with a self-boot engine (SBE), which includes assigning an encryption key to the first extracted SSI; (iv) a hardware thread on a processor core receives updated data for the user workload data; (v) in response to receiving the updated data for the user workload data, the SBE overwrites the encryption key of the first extracted SSI; and (vi) the SBE distinguishes between the first extracted SSI and the updated data for the user workload data. [Brief explanation of the drawing]

[0004] [Figure 1] This is a block diagram of a first embodiment of the system according to the present invention.

[0005] [Figure 2] This is a flowchart showing the method of the first embodiment, which is performed at least partially by the system of the first embodiment.

[0006] [Figure 3] This is a block diagram showing the machine logic (e.g., software) portion of the system according to the first embodiment.

[0007] [Figure 4] This is a block diagram showing a system stack according to an embodiment of the present invention. [Modes for carrying out the invention]

[0008] This “Modes for Carrying Out the Invention” section is divided into the following subsections: (i) Hardware and Software Environment; (ii) Exemplary Embodiments; (iii) Further Comments and / or Embodiments; and (iv) Definitions. I. Hardware and Software Environment

[0009] The present invention may be a system, method, and / or a computer program product. The computer program product may include one (or more) computer-readable storage media having computer-readable program instructions for causing a processor to execute an aspect of the present invention.

[0010] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the aforementioned devices. A non-exclusive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any suitable combination of the aforementioned devices. When used herein, computer-readable storage media should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0011] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers them for storage on a computer-readable storage medium within the respective computing / processing device.

[0012] The computer-readable program instructions for performing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(e.g., Smalltalk® or C++) and conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or this connection may be to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may, in order to perform an aspect of the present invention, execute computer-readable program instructions using state information of computer-readable program instructions and optimize the electronic circuit for personal use.

[0013] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0014] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, so that instructions executed via the processor of a computer or other programmable data processing device create means for realizing a function / operation specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions, which can instruct a computer, a programmable data processing device, and / or other device to function in a particular manner, may be stored in a computer-readable storage medium, so that a computer-readable storage medium storing instructions comprises a product containing instructions that realize a mode of function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0015] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to perform a series of operational steps on that computer, other programmable device, or other device, thereby generating a computer implementation process. The instructions executed on the computer, other programmable device, or other device will then perform the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0016] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for realizing a specified logical function. In some alternative implementations, the functions described in the blocks may be performed in an order other than that shown in the figures. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or sometimes these blocks may be executed in reverse order depending on the related functions. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be realized by a special-purpose hardware-based system that performs a specified function or operation, or executes a combination of special-purpose hardware and computer instructions.

[0017] One embodiment of a possible hardware and software environment for the software and / or method according to the present invention will now be described in detail with reference to the figures. Figure 1 is a functional block diagram showing various parts of a network computer system 100, which includes a server subsystem 102; client subsystems 104, 106, 108, 110, 112; a communication network 114; a server computer 200; a communication device 202; a set of processors 204; a set of input / output (I / O) interfaces 206; a memory device 208; a persistent storage device 210; a display device 212; a set of external devices 214; a random access memory (RAM) device 230; a cache memory device 232; and a program 300.

[0018] Subsystem 102 is representative in many respects of the various computer subsystems in the present invention. Therefore, some parts of subsystem 102 will be described in the following paragraphs.

[0019] Subsystem 102 may be a laptop computer, tablet computer, notebook computer, personal computer (PC), desktop computer, personal digital assistant (PDA®), smartphone, or any programmable electronic device capable of communicating with the client subsystem via network 114. Program 300 is a collection of machine-readable instructions and / or data used to create, manage, and control specific software functions, which will be described in detail below in the “Exemplary Embodiments” subsection of the “Modes for Carrying Out the Invention” section.

[0020] Subsystem 102 can communicate with other computer subsystems via network 114. Network 114 can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and can include wired, wireless, or fiber optic connections. In general, network 114 can be any combination of connections and protocols that support communication between server and client subsystems.

[0021] Subsystem 102 is shown as a block diagram with a number of bidirectional arrows. These bidirectional arrows (without individual reference numbers) represent the communication fabric, through which communication is provided between various components of subsystem 102. This communication fabric can be implemented using any architecture designed to convey data and / or control information between processors (e.g., microprocessors, communication network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, the communication fabric can be at least partially implemented using one or more buses.

[0022] Memory 208 and persistent storage 210 are computer-readable storage media. In general, memory 208 can include any suitable volatile or non-volatile computer-readable storage media. It should be further noted that currently and / or in the near future, (i) there may be a possibility that external device 214 can supply part or all of the memory to subsystem 102; and / or (ii) there may be a possibility that a device external to subsystem 102 can provide memory to subsystem 102.

[0023] Program 300 is stored in persistent storage 210 and is typically accessed and / or executed by one or more of the respective computer processors 204 through one or more memories of memory 208. Persistent storage 210 is (i) more persistent than at least the signals being transmitted; (ii) stores a program (including its software logic and / or data) in a tangible medium (such as a magnetic domain or an optical domain); (iii) less persistent than permanent storage. Alternatively, the data storage may be more persistent and / or permanent than the type of storage provided by persistent storage 210.

[0024] Program 300 may include both machine-readable and executable instructions and / or entity data (i.e., data of the type stored in a database). In this particular embodiment, persistent storage 210 includes a magnetic hard disk drive. Some possible variations include that persistent storage 210 may include a solid state hard drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0025] The medium used by persistent storage 210 may be removable. For example, a removable hard drive may be used for persistent storage 210. Other examples include optical disks and magnetic disks, thumb drives, and smart cards inserted into a drive for transfer to another computer-readable storage medium that is also part of persistent storage 210.

[0026] In these examples, communication device 202 provides communication with other data processing systems or devices external to subsystem 102. In these examples, communication device 202 includes one or more network interface cards. Communication device 202 may provide communication using either or both physical and wireless communication links. Any of the software modules described herein can be downloaded to a persistent storage device (such as persistent storage device 210) through a communication device (such as communication device 202).

[0027] The I / O interface set 206 enables data input and output with other devices that may be locally connected in data communication with the server computer 200. For example, the I / O interface set 206 provides connection to an external device set 214. The external device set 214 typically includes devices such as a keyboard, keypad, touchscreen, and / or several other suitable input devices. The external device set 214 may also include portable computer-readable storage media such as a thumb drive, portable optical or magnetic disk, and memory card. Such portable computer-readable storage media may store software and data used to carry out embodiments of the present invention, such as program 300. In these embodiments, the relevant software may (or may not) be loaded entirely or partially into a persistent storage device 210 via the I / O interface set 206. The I / O interface set 206 also connects to a display device 212 during data communication.

[0028] The display device 212 provides a mechanism for displaying data to the user, and may be, for example, a computer monitor or a smartphone screen.

[0029] The programs described herein are identified based on applications realized in specific embodiments of the present invention. However, any specific program names used herein are for convenience only, and it should be understood that the present invention should not be limited to use in any specific application identified and / or suggested by such names.

[0030] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be comprehensive or to limit oneself to the disclosed embodiments. Numerous modifications and variations will become apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best describe the principles of the embodiments, practical applications, or technical improvements to the art found in the market, or to enable other those skilled in the art to understand the embodiments disclosed herein. II. Exemplary Embodiments

[0031] Figure 2 shows a flowchart 250 illustrating a method according to the present invention. Figure 3 shows a program 300 for performing at least some of the operations of the method in flowchart 250. The method and related software will be described hereafter, with extensive reference to Figure 2 (for the operation blocks of the method) and Figure 3 (for the software blocks), across the following paragraphs.

[0032] The process begins in operation S255, where the user workload data module ("mod") 305 receives a set of user workload data. In some embodiments of the present invention, the set of user workload data includes information detailing the user's workflow process. In some instances, the set of user workload data may include sensitive secure information (SSI) relating to the user's workflow process. In these instances, it is important to ensure that the SSI contained in the user workload data is not compromised by access from an unauthorized source.

[0033] The process proceeds to operation S260, where the SSI extraction mod310 extracts the SSI from the processor core. In some embodiments, the extracted SSI is processed separately from the rest of the user workload data. Furthermore, in some embodiments, an encryption key is created for the SSI initially extracted by the SSI extraction mod310.

[0034] The process proceeds to operation S265, where SSI registration mod315 registers the extracted SSI (as described above in relation to operation S260) with the self-boot engine (SBE). In some embodiments, the registration of the extracted SSI with the SBE may be performed using an application programming interface (API) available on the host. This registration process is described further in subsection III.

[0035] The process proceeds to operation S270, where user workload data mod305 receives updated user workload data. In some embodiments, the updated user workload data may include information such as whether the current work payload is assigned to an existing processing core / thread. Alternatively, user workload data mod305 may determine that it has not yet received updated data.

[0036] The process proceeds to operation S275, where the encryption key mod320 overwrites the encryption key of the extracted SSI. The process finally proceeds to operation S280, where the SSI operation mod325 distinguishes the extracted SSI from the updated user workload data set (as described above in relation to operation S270). III. Further Comments and / or Embodiments

[0037] In some embodiments of the present invention, the following facts, potential problems, and / or areas for improvement are recognized with respect to the current state of the art: (i) In the server world, keeping customer data secure is a critical objective; (ii) In server deployments, the system may fail due to certain hardware (HW) errors / checkstops; (iii) In such cases, it is important to collect HW dump information (e.g., registers, rings, etc.) which will help in analyzing the cause of the specific HW failure; (iv) These registers (SPR / GPR) should typically contain some sensitive customer data as the default workloads executing instructions on these arithmetic units; (v) In order to analyze the cause of the failure, a hardware engineer may want to know which program was running on the system, and this information could be provided from the system's SPR / GPR and then used by a system engineer.

[0038] In some embodiments of the present invention, the following facts, potential problems, and / or areas for improvement are recognized with respect to the current state of the art: (i) One problem with SPR / GPR data dumps is that they may contain sensitive customer data; (ii) This problem is typically exacerbated when a default server hosts multiple workloads belonging to different customers, as there is not necessarily a directional relationship between the hardware data and the customer workloads, making it difficult to determine how the data is encrypted; (iii) Currently, the only way to ensure that customer data is not compromised is to avoid dumping SPR / GPR register data; (iv) However, this limits the ability of system engineers to debug those failures.

[0039] In some embodiments of the present invention, the following facts, potential problems, and / or areas for improvement are recognized with respect to the current state of the art: (i) in a multi-tenant scenario, multiple workloads share common HW resources; (ii) the hypervisor maintains a shared resource pool for different partitions based dynamically on the workloads; (iii) in the case of a hardware checkstop scenario, all HW register dump information (which may inadvertently contain customer-centric data) is required to debug a specific problem, potentially putting customer data at risk; (iv) an out-of-band processor (within a chain of trusted entities) may be useful for encrypting this different workload data based on different keys shared by the workloads; (v) this includes dump data that is needed for debugging when a customer workload crashes.

[0040] In some embodiments of the present invention, the following facts, potential problems, and / or areas for improvement are recognized with respect to the current state of the art: (i) In dedicated systems, there is a way to take a dump via the flexible service processor, which includes customer memory dumps and hardware registers (SPR / GPR) of threads to which customer loads are assigned; (ii) this can be used later by the customer / corporate team to debug the root cause; (iii) Hardware threads involved in executing customer workloads typically have some customer-centric data stored in registers (SPR / GPR) at some point; (iv) Register dumps are important from a security standpoint; (v) In secure systems, the flexible service processor is an untrusted entity, and therefore dumps performed by the FSP are also insecure; (vi) Currently, there is no process to encrypt the data and then retrieve it.

[0041] To secure the data dump, certain embodiments of the present invention push the data set to a secure SBE (Self-Boot Engine) within the chain. In some embodiments, the SBE also has access to all kernel data structures running the customer load. Based on this, the SBE will access hardware registers (SPR / GPR) associated with a particular customer workload based on the kernel task_struct. Alternatively, there may be multiple customer workload instances running on multiple hardware threads at any given time. Since the SBE is the origin of the data dump, it can encrypt the data with the appropriate customer key shared during workload registration. Once the data is encrypted, it can be retrieved from the SBE, and the customer decryption key is required to decrypt the data.

[0042] Some embodiments of the present invention rely on a flexible service processor and how securely it can offload data. This solution describes the extent to which data can be protected at the source itself.

[0043] In some embodiments of the present invention, the following facts, potential problems, and / or areas for improvement are recognized with respect to the current state of the art: (i) In an open power class server, the open BMC is an entity that has no primary role in collecting dump data in the memory-preserving IPL (MPIPL) (it is an unreliable entity); (ii) The self-boot engine (SBE, a reliable entity) is an entity that collects the Architected Register States of all processors; (iii) Each processor has multiple cores, and each core has multiple HW threads; (iv) Each HW thread has a set of SPRs and GPRs that are somewhat different and somewhat common; (v) These SPRs and GPRs are general-purpose registers used to execute low-level instructions for customer payloads; (vi) At any given time, the host kernel assigns a HW thread to a particular customer payload, which can be obtained by examining a kernel data structure such as task_struct that has information related to the customer payload being executed.

[0044] Herein, the present invention demonstrates that configuration registers specific to hardware threads may contain sensitive customer data that the customer does not want the dump collector entity to know. Similarly, multiple such scenarios may exist on a system where multiple customer payloads are running.

[0045] Consider the following example. Assume that Core 0 is assigned to Customer 0 and Core 1 is assigned to Customer 1. In this example, all SPRs and GPRs for Core 0 are as follows: (i) Core 0 has 4 HW threads for low-level execution; (ii) Each thread has 32 GPRs and 64 SPRs; (iii) This results in a total of 384 registers per core (96 x 4 = 384 registers per core). Now, Customer 0 and Customer 1 want to store available information in the 384 registers per core, keep that information secure, and not share it with anyone.

[0046] If sensitive data were to be processed in these registers, this could expose security vulnerabilities in the customer's workload, which may be detrimental from a business perspective. In some cases, a solution to keep register data secure would be necessary.

[0047] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) securely extracting customer-centric data; (ii) requiring customer payloads / workloads to be registered with the SBE and sharing their encryption keys; (iii) this can be done via an API available on the host; (iv) the payload can have its encryption key defined somewhere, where the host can receive and pass it to the SBE.

[0048] In some embodiments, the SBE needs to store a key related to the payload. If there is any update data to the payload (such as whether a new payload is assigned to an existing core / thread), the current key in the SBE is overwritten with it. In some cases, when this infrastructure is operational and a memory and hardware register dump is required in the event of a payload crash, the SBE can use a kernel data structure (such as task_struct or its equivalent) to distinguish between multiple payloads running in the system.

[0049] Essentially, the SBE can distinguish between SPR / GPR on a thread based on different payloads. The dump (memory and registers) is then encrypted per payload with a stored key. For offloading the encrypted dump, there may be several methods, such as a flexible service processor helping to retrieve the dump, or the SBE copying the dump to a reserved memory space that the payload itself can access when it comes back online.

[0050] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) encrypting customer workload register data via a trusted entity such as an SBE; (ii) for this encryption to occur, the customer workload must share an encryption key with the SBE, either via the host kernel or through shared memory accessible to the SBE; and (iii) each customer workload must do the same if it needs to encrypt sensitive register data during MPIPL dump processing and does not want a system engineer to decode it unless the customer has confirmed any other sensitive information.

[0051] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) the SBE can access the host kernel memory and access task_struct or equivalent data structures; (ii) the SBE can obtain from these structures the workload to be executed on a specific thread and is in a position to encrypt the register data (SPR / GPR) with a pre-shared customer workload-specific key; and (iii) once a complete memory dump and register dump are obtained, the customer can review or remove the thread-specific register data, which a system engineer can then use to debug a host kernel / Opal Crash.

[0052] Diagram 400 in Figure 4 shows the system stack diagram. Diagram 400 includes the following components: Payload 1 (402), Payload 2 (404), Power KVM (406), SBE / HBBL / Host Boot (408), FSP / BMC (410), and Power 9 (412).

[0053] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) the customer payload / workload registers with the SBE; (ii) the customer payload / workload shares the same SBE encryption key through an API available on the host; and (iii) the payload can have the encryption key defined somewhere, where the host can receive and pass it to the SBE.

[0054] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) the SBE needs to store an encryption key with respect to the payload; (ii) when a new payload is assigned to an existing core / thread, the new payload will overwrite the current key in the SBE; (iii) assuming this infrastructure is operational and memory and hardware register dumps are required in the event of a payload crash, the SBE can distinguish between multiple payloads running in the system using a kernel data structure (such as task_struct or its equivalent); (iv) distinguishing SPR / GPR on threads based on different payloads; (v) the dumps (memory and registers) are then encrypted per payload with the stored key; (vi) offloading the encrypted dumps may be done in several ways, including using a flexible service processor to retrieve dump-related information; and (vii) the SBE can copy the dump-related information to a reserved memory space that the payload can access when it comes back online. IV. Definitions

[0055] This invention should not be construed as an absolute indication that the subject matter described by the term “this invention” is covered by either the claims at the time of filing or the claims that may ultimately be issued after patent examination; the term “this invention” is used to help the reader gain a general sense that the disclosure herein is considered potentially new, but this understanding is temporary and provisional as indicated by the use of the term “this invention” and may change during patent examination as relevant information evolves and claims may be amended.

[0056] Embodiments: Please refer to the definition of "the present invention" above. Similar considerations apply to the term "embodiment."

[0057] and / or: an inclusive OR; for example, A, B, and / or C means that at least one of A, B, or C is true and applicable.

[0058] including / include / includes: Unless otherwise specified, this means "includes, but not necessarily limited to."

[0059] User / Subscriber: Includes, but is not limited to, (i) an individual; (ii) an artificial intelligence entity capable of fulfilling the role of a user or subscriber; and / or (iii) a group of related users or subscribers.

[0060] Data communication: any type of data communication method known at present or to be developed in the future, including wireless communication, wired communication, and communication paths having wireless and wired portions; data communication is not necessarily limited to (i) direct data communication; (ii) indirect data communication; and / or (iii) data communication in which the format, packetization status, medium, encryption status, and / or protocol remain constant throughout the data communication.

[0061] Receive / Provide / Send / Input / Output / Report: Unless otherwise explicitly stated, these words should not be interpreted as (i) any specific degree of directness relating to the relationship between the subject and the object; and / or (ii) suggesting the absence of any intermediate components, actions, and / or things intervening between the subject and the object.

[0062] Substantial human intervention: A process that occurs automatically (often through the operation of machine logic such as software) with little or no human input; some examples of "substantial human intervention" include (i) a human switching the computer to an alternative power source to ensure that processing continues uninterrupted when the grid power goes out while the computer is performing a complex operation; (ii) a human confirming whether a computer should actually start performing a resource-intensive operation (in this case, the confirmation process, when considered in isolation, involves substantial human intervention, but the resource-intensive operation itself does not involve any substantial human intervention, although a simple binary confirmation by a human is required); and (iii) a computer using machine logic making an important decision (e.g., a decision to keep all planes on the ground in anticipation of bad weather), but the computer needs a simple binary confirmation by a human source before implementing that important decision.

[0063] Automatic: Without any human intervention.

[0064] Module / Submodule: Any collection of hardware, firmware, and / or software that works to perform a certain function, regardless of whether the module is (i) in a single local proximity; (ii) distributed over a wide area; (iii) in a single proximity within a larger software code; (iv) located within a single software code; (v) located within a single storage device, memory, or medium; (vi) mechanically connected; (vii) electrically connected; and / or (viii) connected by data communication.

[0065] Computer: Any device with considerable data processing capability and / or machine-readable instruction reading capability, including, but not limited to, desktop computers, mainframe computers, laptop computers, field-programmable gate array (FPGA)-based devices, smartphones, personal digital assistants (PDAs), wearable or implantable computers, embedded computer devices, and application-specific integrated circuit (ASIC)-based devices.

Claims

1. The hardware thread on the processor core receives a set of user workload data, which includes confidential secure information (SSI); A step of extracting the SSI from the processor core to obtain a first extracted SSI; The first extracted SSI is registered with the self-boot engine (SBE), where the registration includes assigning an encryption key to the first extracted SSI; The step in which the hardware thread on the processor core receives update data for the set of user workload data; The step of overwriting the encryption key of the first extracted SSI in response to receiving the updated data of the set of user workload data; and The SBE performs the step of distinguishing between the first extracted SSI and the updated data of the user workload data set. A method for providing this.

2. The method according to claim 1, wherein the first extracted SSI and the updated data of the set of user workload data share the same encryption key.

3. The method according to claim 1, wherein the distinction between the first extracted SSI and the updated data of the user workload data set is performed by a kernel data structure.

4. moreover, The method according to claim 1, further comprising the step of the flexible service processor offloading the first extracted SSI set by retrieving the data contained in the first extracted SSI set.

5. moreover, The method according to claim 1, further comprising the step of the SBE offloading the first extracted SSI set by copying the data contained in the first extracted SSI set to a reserved memory space.

6. The method according to any one of claims 1 to 5, wherein the encryption key is shared with the SBE through the host kernel.

7. An operation in which a hardware thread on a processor core receives a set of user workload data, wherein the set of user workload data includes confidential secure information (SSI), An operation to extract the SSI from the processor core and obtain the first extracted SSI, The operation of registering the first extracted SSI with the self-boot engine (SBE), wherein the registration includes assigning an encryption key to the first extracted SSI. The operation in which the hardware thread on the processor core receives updated data for the set of user workload data, In response to receiving the updated data for the set of user workload data, the operation of overwriting the encryption key of the first extracted SSI, and The SBE performs the operation of distinguishing between the first extracted SSI and the updated data of the user workload data set. The processor is made to perform multiple operations, including Computer program.

8. The computer program according to claim 7, wherein the first extracted SSI and the update data of the set of user workload data share the same encryption key.

9. The computer program according to claim 7, wherein the distinction between the first extracted SSI and the updated data of the user workload data set is performed by a kernel data structure.

10. moreover, The computer program according to claim 7, further comprising the operation of a flexible service processor offloading the first extracted SSI set by retrieving the data contained in the first extracted SSI set.

11. moreover, The computer program according to claim 7, comprising the operation by which the SBE offloads the first extracted SSI set by copying the data contained in the first extracted SSI set to a reserved memory space.

12. The computer program according to any one of claims 7 to 11, wherein the encryption key is shared with the SBE through the host kernel.

13. One or more processors; Machine-readable storage devices; and The computer code stored in the machine-readable storage device, the computer code contains, The operation in which a hardware thread on a processor core receives a set of user workload data, where this set of user workload data includes confidential secure information (SSI). An operation to extract the SSI from the processor core and obtain the first extracted SSI, The operation of registering the first extracted SSI with the self-boot engine (SBE), wherein the registration includes assigning an encryption key to the first extracted SSI. The operation in which the hardware thread on the processor core receives updated data for the set of user workload data, In response to receiving the updated data for the set of user workload data, the operation of overwriting the encryption key of the first extracted SSI, and The SBE performs the operation of distinguishing between the first extracted SSI and the updated data of the user workload data set. Includes instructions and data for causing one or more processors to perform multiple operations, including the above. A computer system (CS) equipped with [a specific feature / ability].

14. The CS according to claim 13, wherein the first extracted SSI and the updated data of the set of user workload data share the same encryption key.

15. The CS according to claim 13, wherein the distinction between the first extracted SSI and the updated data of the user workload data set is performed by a kernel data structure.

16. moreover, The CS according to claim 13, further comprising the operation of the flexible service processor offloading the first extracted SSI set by retrieving the data contained in the first extracted SSI set.

17. moreover, The CS according to claim 13, further comprising the operation by which the SBE offloads the first extracted SSI set by copying the data contained in the first extracted SSI set to a reserved memory space.

18. The CS according to any one of claims 13 to 17, wherein the encryption key is shared with the SBE through the host kernel.

Images