Limiting number of violation interrupts to switch central processing unit to system management mode

Abstract

Disclosed herein is a system for limiting the rate at which a system management interrupt can suspend normal execution of a central processing unit (CPU) by switching the operating mode of the CPU from one of a real mode or a protected mode to a system management mode. The rate limit imposed by the system provides a protection against network attacks (e.g., distributed denial of service (DDoS) attacks) from malicious behaviorists, and ensures that the CPU may be more efficient in executing workloads (e.g., processing threads).

Description

Background Technology

[0001] Some central processing units (CPUs) of computing devices (e.g., the x86 instruction set architecture originally developed by Intel) can operate in different operating modes (referred to as "modes" here). These different modes include real mode, protected mode, and system management mode. When operating in real mode, the memory addresses used by the CPU of a computing device (e.g., a web server) correspond to actual locations in memory. However, when operating in real mode, the operating system of the computing device cannot perform multitasking. When operating in protected mode, the operating system of the computing device can implement virtual memory, and therefore, the operating system can safely perform multitasking.

[0002] The CPU of a computing device typically boots into live mode (e.g., to implement a boot sequence), and then the operating system switches the CPU's operating mode from live mode to protected mode. For example, the CPU in a web server preferably operates in protected mode so that it can perform multiple workloads on behalf of (multiple) cloud tenants. Operating the CPU in live mode or protected mode is often referred to as enabling the CPU's "normal" execution.

[0003] When the CPU is switched to system management mode, normal CPU execution is suspended. System management mode provides a unique processing environment isolated from the operating system and / or software applications. That is, the CPU executes system management mode code in a separate address space (e.g., System Management Random Access Memory (SMRAM)), which is inaccessible when the CPU operates in real mode and protected mode. Therefore, by switching the CPU to system management mode, the CPU's control is taken away from the operating system of the computing device.

[0004] The CPU can be switched to system management mode via a System Management Interrupt (SMI). A challenge associated with SMIs is their lack of specificity. For example, as supported by the operating system, a SMI can be invoked due to a memory error related to the execution of a specific processing thread running on the CPU. However, when invoked, the SMI does not, for example, identify (i.e., flag) a specific processing thread executing on the CPU. Instead, when a SMI is invoked and the CPU switches to system management mode so that the SMI can be serviced, all processing threads executing concurrently on the CPU (e.g., single-core CPU, multi-core CPU) are abruptly suspended.

[0005] Therefore, system management interruptions disrupt multiple workloads executed on behalf of cloud tenants via the CPU. This disruption of multiple workloads provides malicious actors with a means to launch cyberattacks. For example, malicious actors can launch distributed denial-of-service (DDoS) attacks by requesting a large number of unauthorized system management interrupts or by using malware executed by a compromised operating system. In cloud systems comprising thousands or even millions of web servers (e.g., one or more data centers), the ability to cause this type of damage can have serious consequences such as processing delays, increased costs, and customer dissatisfaction. Summary of the Invention

[0006] The techniques disclosed herein implement a system that limits the rate at which system management interrupts can halt normal CPU execution by switching the operating mode of the central processing unit (CPU) from either real mode or protected mode to system management mode. The rate limit imposed by the system provides a protective layer against network attacks from malicious actors (e.g., distributed denial-of-service (DDoS) attacks) and ensures that the CPU is more efficient in executing workloads (e.g., processing threads).

[0007] The system management interrupts described in this article are out-of-band system management interrupts because they are handled by a firmware agent rather than the operating system. The firmware agent's task is to invoke the system management interrupt based on received interrupt invocation requests. In one example, the firmware agent is the Baseboard Management Controller (BMC). However, other types of firmware installed on the main board of a computing device can be used as the firmware agent described in this article.

[0008] A Network Controller (BMC) is a service processor that uses sensors and / or other mechanisms to monitor the physical status of device memory, other hardware components, and / or peripherals. The BMC is configured on the main board of a computing device (e.g., a web server) and can communicate remotely via a shared or dedicated network interface card (NIC). In one example, the BMC is configured to perform tasks that would otherwise need to be performed by a user physically accessing a web server in a server rack. For example, consider a cloud platform with a large number of web servers (e.g., Amazon Web Services, Google Cloud Platform, Microsoft Azure) that executes cloud tenant workloads via a data plane; the BMC is part of a manageability subsystem that forms part of the control plane within the cloud platform. The control plane can be used to collect telemetry data across web servers for management or operational purposes. Therefore, the BMC is configured to collect and report telemetry data from web servers configured within the cloud platform's data centers(s).

[0009] Therefore, the BMC is configured to perform monitoring operations and / or invoke system management interrupts based on monitoring operations and / or interrupt call requests (e.g., received from the operating system). Different types of system management interrupts exist. For example, a first type of system management interrupt can be invoked to manage or debug errors in system hardware (e.g., memory errors, chipset errors, etc.). A second type of system management interrupt can be invoked to implement telemetry acquisition (e.g., via telemetry dump requests). A third type of system management interrupt can be invoked to implement power control functions (e.g., managing a voltage regulator module). A fourth type of system management interrupt can be invoked to implement safety functions (e.g., device shutdown due to CPU overheating). A fifth type of system management interrupt can be invoked to install firmware updates (e.g., Unified Extensible Firmware Interface (UEFI) updates). These specific types of system management interrupts are provided as examples, and it should be understood in the context of this disclosure that other types of system management interrupts can be invoked to switch the CPU from live mode or protected mode to system management mode.

[0010] The firmware agent described in this article (such as BMC) is configured to limit the number of unauthorized interrupts that can be invoked to switch the CPU's operating mode from live mode or protected mode to system management mode. The firmware agent defines a threshold number of interrupts that can be invoked. The firmware agent then tracks the number of interrupts that have been allowed to be invoked and determines if the number of interrupts has met (e.g., reached, satisfied) the interrupt threshold. Once the number of interrupts meets the interrupt threshold, the firmware agent blocks the invocation of any additional interrupts. This limits the rate at which unauthorized interrupts can interfere with the normal execution of the CPU. As mentioned above, unauthorized interrupts can be part of a DDoS attack that requests a large number of system management interrupts in a short period. Other device impairments, weaknesses, and / or vulnerabilities can lead to other types of cyberattacks that interfere with the normal execution of the CPU via the use of interrupts.

[0011] The firmware agent is configured to define a threshold number of interrupts within a predetermined time period (e.g., one hour, one day, one week). Therefore, tracing implemented by the firmware agent is performed during the predetermined time period. When the predetermined time period expires, tracing restarts in the next predetermined time period (e.g., the next hour, the next day, the next week). More specifically, when the predetermined time period expires, the number of traced interrupts is reset to zero.

[0012] In one implementation, the number of interrupt thresholds is statically defined for a predetermined time period. For example, an administrator user can define the number of interrupts allowed to be invoked by a computing device during a predetermined time period.

[0013] In another implementation, the number of interruption thresholds is dynamically defined for a predetermined time period. For example, the firmware agent may include an artificial intelligence model configured to analyze interruption call requests received over an extended time period, which may include multiple consecutive predetermined time periods (e.g., the last 100 or 1000 hours, the last 100 days, the last 10 weeks). The AI ​​model is then configured to predict the frequency of compliant interruptions requested within the predetermined time periods as output. The number of interruption thresholds can be determined based on the predicted frequency. Furthermore, the analysis performed by the AI ​​model can continue, allowing the number of interruption thresholds to be continuously updated or dynamically changed based on the predicted output. Therefore, the operational goal of the number of interruption thresholds is to allow compliant interruption calls but prevent illegitimate interruption calls.

[0014] In the various examples described herein, a threshold number of interrupts is defined for specific types of interrupts. Furthermore, the threshold numbers for different types of interrupts can be stored in a table, which can be referenced when an interrupt invocation request is received. The firmware agent may include different interfaces for receiving interrupt invocation requests, and these different interfaces may correspond to different types of interrupts accordingly. Therefore, a type of interrupt is associated with an entry in the table, and when an interrupt invocation request is received at the interface corresponding to the interrupt type, the firmware agent maps the interrupt invocation request to an entry in the table to determine whether the interrupt invocation should be allowed or blocked.

[0015] The firmware agent is configured to invoke system management interrupts via toggling general-purpose input / output (GPIO) pins. The toggled GPIO pin generates and sends an interrupt signal to the CPU to suspend normal execution and switch from real mode or protected mode to system management mode, enabling interrupt servicing. In various examples, specific interrupt types have their own dedicated GPIO pins, allowing the CPU to distinguish between different interrupt types.

[0016] Therefore, the system described in this paper limits the rate at which system management interrupts can suspend the normal execution of the CPU. The rate limit imposed by the system provides a protective layer against network attacks from malicious actors (e.g., distributed denial-of-service (DDoS) attacks) and ensures that the CPU can be more efficient in executing workloads (e.g., processing threads). The system described in this paper can achieve other technical advantages.

[0017] This summary is provided to introduce a series of concepts in a simplified form, which are further described in the detailed embodiments described below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. For example, the term "technology" can refer to (multiple) systems, (multiple) methods, computer-readable instructions, (multiple) modules, algorithms, hardware logic, and / or (multiple) operations permitted in the context described above and throughout this document. Attached Figure Description

[0018] Specific embodiments are described with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. Identical reference numerals in different drawings indicate similar or identical items. References to individual items among multiple items can use reference numerals with letters in a letter sequence to refer to each individual item. General references to these items can use specific reference numerals without a letter sequence.

[0019] Figure 1 An example environment is shown where a computing device (e.g., a web server) is configured to limit the rate at which system management interrupts can pause the normal execution of the central processing unit (CPU).

[0020] Figure 2A It shows Figure 1 An extended version of the example environment, in which rate limiter tables are created, maintained, and referenced in the firmware agent to limit the rate at which system management interrupts can pause normal CPU execution.

[0021] Figure 2B It shows Figure 1 An extended version of the example environment, such as Figure 2A As shown, this illustrates the number of allowed interruptions that are met at a later time, thus preventing call interruption.

[0022] Figure 3 An example diagram is shown, illustrating how the threshold number of allowed interruptions is defined and / or updated over time.

[0023] Figure 4 An example flowchart is shown for an example method of limiting the rate at which system management interrupts can suspend the normal execution of the central processing unit (CPU).

[0024] Figure 5 An example flowchart is shown, which iterates through multiple interrupts at a rate that limits the rate at which system management interrupts can suspend the normal execution of the central processing unit (CPU).

[0025] Figure 6This is an example computer architecture diagram, which illustrates the illustrative computer hardware and software architecture of a computing system capable of implementing various aspects of the technologies and solutions presented herein. Detailed Implementation

[0026] The following detailed embodiments disclose a technique and solution for limiting the rate at which system management interrupts can suspend the normal execution of the central processing unit (CPU) by switching the CPU's operating mode from either real mode or protected mode to system management mode. The rate limiting imposed by the system provides a layer of protection against network attacks from malicious actors (e.g., distributed denial-of-service (DDoS) attacks) and ensures that the CPU can be more efficient in executing workloads (e.g., processing threads). References below... Figures 1 to 6 To describe various examples, scenarios, and aspects.

[0027] Figure 1 An example environment is illustrated where computing device 102 (e.g., a web server) is configured to limit the rate at which system management interrupts can suspend the normal execution of central processing unit (CPU) 104. As shown, computing device 102 includes a main board 106 (alternatively referred to as a "mother" board), and CPU 104 is connected to this main board. As described above, CPU 104 can operate in real mode 108, protected mode 110, and system management mode 112, and operating CPU 104 in real mode 108 or protected mode 110 is generally referred to as enabling "normal" execution of the CPU.

[0028] When CPU 104 is switched to system management mode 112, normal execution of CPU 104 is suspended. This is because system management mode 112 provides a unique processing environment isolated from the operating system and / or software applications. Specifically, CPU 104 executes system management mode code in a separate address space (e.g., system-managed random access memory (SMRAM)), which is inaccessible when CPU 104 operates in real mode 108 and protected mode 110. Therefore, by switching CPU 104 to system management mode 112, control of CPU 104 is taken away from the operating system of computing device 102.

[0029] CPU 104 can be switched to system management mode 112 via a system management interrupt (SMI) call. The system management interrupts described herein are out-of-band interrupts because they are handled by firmware agent 114 rather than the operating system of computing device 102. The task of firmware agent 114 is to invoke the system management interrupt based on interrupt call request 116. See below for reference. Figures 2A to 2BIn one example further described, firmware agent 114 is a baseboard management controller (BMC). However, other types of firmware mounted on the main circuit board 106 of computing device 102 can be used as firmware agent 114 as described herein.

[0030] The task of firmware agent 114 is to use sensors and / or other mechanisms to monitor the physical state of device memory 116 (where the operating system 118 and other applications 120 described above are stored), hardware components 122, and / or peripheral devices 124. Therefore, firmware agent 114 is configured to perform monitoring operations and / or invoke system management interrupts based on monitoring operations and / or interrupt call requests 116 (e.g., received from the operating system 118, hardware components 122, and / or peripheral devices 124).

[0031] Unfortunately, not all interrupt call requests 116 received by the firmware agent 114 are compliant. For example, as part of a cyberattack, compromised software and / or hardware 126 can issue illegitimate interrupt call requests to interfere with the normal execution of the CPU 104. Therefore, Figure 1 The diagram illustrates firmware agent 114 with a compliant interrupt 128 to be invoked and a non-compliant interrupt 130 to be invoked. However, because system management interrupts do not target (e.g., identify) a specific processing thread executing on CPU 104 for a pause, all processing threads executing concurrently on CPU 104 (e.g., single-core CPU, multi-core CPU) are abruptly paused. As mentioned above, such a general pause can severely impact cloud platforms because a large number of workloads executed for various cloud tenants are disrupted (e.g., experience latency).

[0032] Therefore, firmware agent 114 is configured to limit the number of unauthorized interrupts 130 by defining a threshold number 132 of allowed interrupt calls. As described in further detail below, firmware agent 114 tracks the number of interrupts that have been allowed to be called and determines when the number of interrupts meets (e.g., reaches, conforms to) the threshold number 132 of allowed interrupt calls. Once the number of interrupts meets the threshold number 132 of allowed interrupt calls, firmware agent 114 prevents the invocation of additional interrupts. This limits the rate at which unauthorized interrupts 130 may interfere with the normal execution of CPU 104.

[0033] Figure 2A It shows Figure 1 An extended version of the example environment, in which rate limiter table 202 is created, maintained, and referenced in firmware agent 114 to limit the rate at which system management interrupts can halt the normal execution of CPU 104. Figure 2AIn this context, the firmware agent is the Baseboard Management Controller (BMC) 204. As described above, the BMC 204 is configured on the main board 106 of the computing device 102 (e.g., a network server) and can communicate remotely via a shared or dedicated network interface card (NIC).

[0034] In one example, BMC 204 is configured to perform tasks that would otherwise need to be performed by users of web servers in a physical access server rack. For instance, consider a cloud platform with a large number of web servers (e.g., Amazon Web Services, Google Cloud Platform, Microsoft Azure) executing cloud tenant workloads via a data plane; BMC 204 is part of a manageability subsystem that forms part of the control plane within the cloud platform. The control plane can be used to collect telemetry data across web servers for management or operational purposes. Therefore, BMC 204 is configured to collect and report telemetry data from web servers configured within the cloud platform's (multiple) data centers.

[0035] The System Management Interrupts (SMIs) handled by the BMC 204 exist in different types 206. For example, a first type of System Management Interrupt 206(1) can be invoked to manage or debug errors in the system hardware (e.g., memory errors, chipset errors, etc.). A second type of System Management Interrupt 206(2) can be invoked to perform telemetry acquisition (e.g., via telemetry dump requests). A third type of System Management Interrupt 206(3) can be invoked to perform power control functions (e.g., managing the voltage regulator module). For ease of discussion, refer to Figures 2A to 2B These three types of system management interrupts are illustrated. However, in the context of this disclosure, it should be understood that other types of system management interrupts can be invoked to switch the CPU 104 from real mode or protected mode to system management mode. For example, another type of system management interrupt can be invoked to implement security functions (e.g., device shutdown due to CPU overheating) or to install firmware updates (e.g., Unified Extensible Firmware Interface (UEFI) update).

[0036] As described above, BMC 204 is configured to define a threshold number of 132 interrupts that are allowed to be invoked. Figure 2A In this context, BMC 204 defines the threshold number of interrupts for different types of system management interrupts and stores the information in rate limiter table 202. As shown in the figure, rate limiter table 202 includes a structure with a column 208 specifying the type of system management interrupt, a column 210 specifying the threshold number of allowed interrupts, a column 212 specifying a predetermined time period for limiting the rate of system management interrupts, and a column 214 specifying the current number of interrupts that have been allowed to be invoked.

[0037] In addition to defining the threshold number 132 of allowed interrupts specified in definition column 210, BMC 204 is also configured to define a predetermined time period for rate limiting (e.g., one hour, one day, one week). Therefore, the tracing implemented by BMC 204 is performed during the predetermined time period. When the predetermined time period expires, tracing restarts in the next predetermined time period (e.g., the next hour, the next day, the next week). More specifically, when the predetermined time period expires, the current number 214 of interrupts is reset to zero.

[0038] BMC 204 may include different interfaces 216(1-3) for receiving interrupt call requests, and these different interfaces 216(1-3) may correspond accordingly to different types of interrupts 206(1-3). Furthermore, one type of interrupt is associated with an entry in rate limiter table 202. For example, SMI 206(1) type corresponds to entry 218(1) in rate limiter table 202 specifying a hardware error. SMI 206(2) type corresponds to entry 218(2) in rate limiter table 202 specifying telemetry acquisition. SMI 206(3) type corresponds to entry 218(3) in rate limiter table 202 specifying power control.

[0039] Therefore, when BMC 204 receives an interrupt call request 220(1) of type 206(1) at interface 216(1), BMC 204 maps the interrupt call request 220(1) to entry 218(1) in rate limiter table 202 to determine whether the interrupt call should be allowed or blocked. Similarly, when BMC 204 receives an interrupt call request 220(2) of type 206(2) at interface 216(2), BMC 204 maps the interrupt call request 220(2) to entry 218(2) in rate limiter table 202 to determine whether the interrupt call should be allowed or blocked. Similarly, when BMC 204 receives an interrupt call request 220(3) of type 206(3) at interface 216(3), BMC 204 maps the interrupt call request 220(3) to entry 218(3) in rate limiter table 202 to determine whether the interrupt call should be allowed or blocked.

[0040] BMC 204 includes an interrupt tracker 222 that receives interrupt call requests 220 (1-3) and references 224, or checks the corresponding entries 218 (1-3) in the rate limiter table 202 to determine whether a single interrupt call request should be allowed or blocked. In the example of a hardware error interrupt type (i.e., type 206 (1)), entry 218 (1) indicates that four hardware error system management interrupts are allowed per day, and for the current day being tracked, BMC 204 has already allowed two hardware error system management interrupts to be called. Therefore, interrupt tracker 222 allows interrupt 226 to be called based on interrupt call request 220 (1) because the current number of interrupts (i.e., two) has not yet met (e.g., less than) the threshold number of interrupts allowed (i.e., four). Furthermore, interrupt tracker 222 increments the current number of interrupts by 228 after allowing / calling the interrupt. That is, the number 2 in column 214 of entry 218 (1) is incremented to 3 (e.g., as shown in the original text). Figure 2B (As shown).

[0041] In the example of the telemetry acquisition interrupt type (i.e., type 206(2)), entry 218(2) indicates that two telemetry acquisition system management interrupts are allowed per day, and for the current day being tracked, BMC 204 has already allowed the invocation of one telemetry acquisition system management interrupt. Therefore, interrupt tracker 222 allows interrupt 226 to be invoked based on interrupt invocation request 220(2) because the current number of allowed interrupts (i.e., one) has not yet met the threshold number of allowed interrupts (i.e., two). Furthermore, interrupt tracker 222 increments the current number of interrupts by 228 after allowing / invoking the interrupt. That is, the number 1 in column 214 of entry 218(2) is incremented to 2 (e.g., as shown in the original text). Figure 2B (As shown).

[0042] In the example of power control interrupt type (i.e., type 206(3)), entry 218(3) indicates that six power control system management interrupts are allowed per day, and for the current day being tracked, BMC 204 has already allowed the invocation of three power control management interrupts. Therefore, interrupt tracker 222 allows interrupt 226 to be invoked based on interrupt invocation request 220(3) because the current number of allowed interrupts (i.e., three) has not yet met the threshold number of allowed interrupts (i.e., six). Furthermore, interrupt tracker 222 increments the current number of interrupts by 228 after allowing / invoking an interrupt. That is, the number 3 in column 214 of entry 218(3) is incremented to 4 (e.g., ...). Figure 2B (As shown).

[0043] In various examples, once it is determined that a system management interrupt can be invoked, the BMC 204 invokes the system management interrupt by toggling the GPIO pin 232. The toggled GPIO pin 232 generates and sends an interrupt signal to the CPU 104 to suspend normal execution and switch from real mode or protected mode to system management mode, making the interrupt serviceable. In various examples, each type of interrupt has its own dedicated GPIO pin, so the CPU 104 can distinguish between different types of interrupts. For example, a system management interrupt of type 206(1) invoked based on interrupt call request 220(1) is mapped to GPIO pin 236 via application programming interface 234(1). A system management interrupt of type 206(2) invoked based on interrupt call request 220(2) is mapped to GPIO pin 238 via application programming interface 234(2). And a system management interrupt of type 206(3) invoked based on interrupt call request 220(3) is mapped to GPIO pin 232 via application programming interface 234(3).

[0044] Figure 2B It shows Figure 1 An extended version of the example environment, such as Figure 2A As shown, however, this illustrates a scenario where an interrupt call is blocked when a threshold number of allowed interrupts of at least one type of system management interrupt is later met. As shown in the figure, Figure 2B The rate limiter table 202 has been updated to reflect... Figure 2A Interrupts are allowed in the middle. Next, when BMC 204 receives the next / new round of interrupt call request 240 (1-3) via interface 216 (1-3) after receiving the previous round of interrupt call request 220 (1-3) (but on the same day), interrupt tracker 222 executes the above-mentioned interrupt call request 240 (1-3). Figure 2A The same process as described.

[0045] and Figure 2A The discussion is similar. Figure 2B Interrupt tracker 222 allows interrupt 226 to be invoked based on interrupt call request 240(1) because the current number of allowed interrupts (i.e., three) in entry 218(1) has not yet met the threshold number of allowed interrupts (i.e., four). Interrupt tracker 222 allows interrupt 226 to be invoked based on interrupt call request 240(3) because the current number of allowed interrupts (i.e., four) in entry 218(3) has not yet met the threshold number of allowed interrupts (i.e., six). However, in Figure 2BIn this context, interrupt tracker 222 prevents interrupts from being invoked based on interrupt call request 240(2) because the current number of allowed interrupts (i.e., two) in entry 218(2) indicates that the threshold number of allowed interrupts (i.e., two) has been met (i.e., the current number of allowed interrupts is already equal to the threshold). Therefore, interrupt tracker 222 prevents interrupts from being invoked, as shown via element 242, and GPIO pin 238 is not toggled and no signal is sent to CPU 104.

[0046] Figure 3 An example diagram is shown illustrating how the number of allowed interruption thresholds 132 can be defined and / or updated over time. In one implementation, the number of interruption thresholds 132 is statically defined and / or updated over a predetermined time period based on user input 304. For example, an administrator user can define... Figures 2A to 2B The number of thresholds shown in Table 202 of the rate limiter.

[0047] In another implementation, the number of interrupt thresholds 132 is dynamically defined and / or updated 306 within a predetermined time period. For example, firmware agent 114 may include and / or access artificial intelligence model 308, which is configured to receive and analyze past interrupts 310 (e.g., interrupt call requests, invoked system management interrupts) that occurred within an extended time period. The extended time period includes multiple consecutive predetermined time periods (e.g., the last 100 or 1000 hours, the last 100 days, the last 10 weeks). Past interrupts 310 include characteristics 312 related to the timing of the interrupt, the type of the interrupt, etc. The artificial intelligence model 308 is then configured to predict, as output, the frequency 314 of compliant interrupt requests 130 within the predetermined time period. The number of interrupt thresholds 132 can be defined and / or updated based on the predicted frequency 314. Furthermore, the analysis performed by the artificial intelligence model 308 can continue, such that the number of interrupt thresholds 132 is continuously updated or dynamically changed based on the predicted frequency 314.

[0048] Artificial intelligence model 308 can be any of a variety of predictive models. For example, artificial intelligence model 308 can use any of the following: neural networks (e.g., convolutional neural networks, recurrent neural networks such as Long Short-Term Transformer (TRansformer), Naive Bayes, k-Nearest Neighbors algorithm, majority classifier, support vector machine, random forest, classification and regression tree (CART), gradient boosting decision tree (GBDT), etc.

[0049] Figure 4 and Figure 5 Indicates according to Figures 1 to 3 The example process is implemented using various examples described in the text. Figure 4 and Figure 5The example operations shown can be performed in, for example... Figure 1 The computing device 102 shown is implemented on or otherwise embodied in the computing device.

[0050] The order in which these operations are described is not intended to be construed as a limitation, and any number of operations described can be combined and / or implemented in parallel in any order. Furthermore, Figure 4 and Figure 5 The operations described herein can be implemented in hardware, software, and / or a combination thereof. In the context of software, an operation represents a computer-executable instruction that, when executed by one or more processing units, causes one or more processing units to perform the described operation. For example, the modules and other components described herein can be stored in a computer-readable storage medium and executed by at least one processing unit to perform the described operations.

[0051] Figure 4 A flowchart of an example method 400 for limiting the rate at which a system management interrupt can suspend the normal execution of the central processing unit (CPU) is shown. Figure 4 The operations can be implemented by firmware agent 114 (e.g., baseboard management controller (BMC)).

[0052] At operation 402, the firmware agent defines the threshold number of interrupts that allow the central processing unit to switch its operating mode from real operating mode or protected operating mode to system management operating mode.

[0053] At operation 404, firmware agent tracking has been enabled by multiple interrupts that allow the central processing unit to switch its operating mode from real operating mode or protected operating mode to system management operating mode.

[0054] At operation 406, the firmware agent determines the number of interrupts that has met the interrupt threshold based on the trace.

[0055] At operation 408, the firmware agent uses this determination to prevent additional interrupts from being allowed to switch the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode.

[0056] Figure 5 A flowchart of example method 500 is shown, which iterates through multiple interrupts to limit the rate at which a system management interrupt can suspend the normal execution of the central processing unit (CPU). Figure 5 The operations can be implemented by firmware agent 114 (e.g., baseboard management controller (BMC)).

[0057] At operation 502, the firmware agent defines the threshold number of interrupts that allow the central processing unit to switch its operating mode from real operating mode or protected operating mode to system management operating mode.

[0058] At operation 504, the firmware agent receives an interrupt call request.

[0059] At operation 506, the firmware agent determines whether the current number of interrupts that have been allowed to switch the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode meets (e.g., equals) the number of interrupts.

[0060] If, at operation 506, it is determined that the current number of interrupts that allow switching the central processing unit's operating mode from real operating mode or protected operating mode to system management operating mode does not meet the interrupt threshold (e.g., the current number is less than the threshold), the process continues to operation 508, where the firmware agent invokes the interrupt based on the interrupt invocation request. Furthermore, at operation 510, the firmware agent increments the current number of interrupts by 1. Then, when the next interrupt invocation request is received, the process can return to operation 504.

[0061] On the other hand, if at operation 506 it is determined that the current number of interrupts that allow the switching of the central processing unit's operating mode from real operating mode or protected operating mode to system management operating mode does indeed meet the interrupt threshold number (e.g., the current number is already equal to the threshold number), then the process continues to operation 512, where the firmware agent blocks interrupt calls based on interrupt call requests. Then, when the next interrupt call request is received, the process can return to operation 504.

[0062] Figure 6 This is a computer architecture diagram, illustrating the computer hardware and software architecture of computing devices that can implement the various technologies presented in this article. Specifically, Figure 6 The architecture shown can be used to implement Figure 1 The computing device 102 in the middle.

[0063] Figure 6The computing device 600 shown includes a central processing unit 602 (“CPU”), system memory 604 (including random access memory 606 (“RAM”) and read-only memory (“ROM”) 608), and a system bus 610 coupling the memory 604 to the CPU 602. A basic input / output system (“BIOS” or “firmware”) containing basic routines that facilitate the transfer of information (such as during startup) between components within the computing device 600 may be stored in the ROM 608. The computing device 600 also includes a mass storage device 612 for storing an operating system 614, applications 615, and / or other types of programs.

[0064] Mass storage device 612 is connected to CPU 602 via a mass storage controller connected to bus 610. Mass storage device 612 and its associated computer-readable medium provide non-volatile storage for computing device 600. While the description of computer-readable medium herein refers to mass storage devices (such as hard disks, CD-ROM drives, DVD-ROM drives, or USB storage keys), those skilled in the art will understand that computer-readable medium can be any available computer storage or communication medium accessible to computing device 600.

[0065] Communication media include computer-readable instructions, data structures, program modules, or other data in modulated data signals, such as carrier waves or other transmission mechanisms, and include any transport medium. The term "modulated data signal" refers to a signal whose characteristics are altered or set in a certain way to encode information in the signal. By way of example and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, radio frequency, infrared, and other wireless media). Any combination of the above should also be included within the scope of computer-readable media.

[0066] By way of example and not limitation, computer storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). For example, computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory, or other solid-state memory technologies, CD-ROM, digital versatile disc (“DVD”), HD-DVD, Blu-ray, or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by computing device 600. For the purposes of the claims, the phrase “computer storage media” and its variations do not include waves or signals themselves or communication media.

[0067] Depending on the configuration, computing device 600 can operate in a networked environment via a network (such as network 616) and a logical connection to a remote computer. Computing device 600 can be connected to network 616 via network interface unit 618 connected to bus 610. It should be understood that network interface unit 618 can also be used to connect to other types of networks and remote computer systems.

[0068] It should be understood that, when loaded into and executed, the software components described herein can transform the CPU 602 and the entire computing device 600 from a general-purpose computing device into a special-purpose computing device, tailored to facilitate the functionality presented herein. The CPU 602 can be constructed from any number of transistors or other discrete circuit elements, which can individually or collectively present any number of states. More specifically, the CPU 602 can operate as a finite state machine in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions can transform the CPU 602 by specifying how it transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the CPU 602. Figure 6 It is also shown that firmware agent 114 is connected to bus 610.

[0069] Encoding the software modules presented herein can also transform the physical structure of the computer-readable medium presented herein. In different implementations of this specification, the specific transformation of the physical structure can depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable medium, whether the computer-readable medium is characterized as a primary or secondary storage device, etc. For example, if the computer-readable medium is implemented as a semiconductor-based memory, the software disclosed herein can be encoded on the computer-readable medium by transforming the physical state of the semiconductor memory. For example, the software can transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software can also transform the physical state of such components to store data thereon.

[0070] The public information presented herein also covers the topics set forth in the following clauses.

[0071] Example Clause A, a method implemented by a firmware agent for limiting the number of unauthorized interrupts that switch the operating mode of the central processing unit (CPU) from a real operating mode or a protected operating mode to a system management operating mode, includes: defining a threshold number of interrupts that are allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode; tracking the number of interrupts that have been allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode; based on the tracking, determining that the number of interrupts has met the threshold number of interrupts; and based on the determination, preventing additional interrupts from being allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode.

[0072] Example Clause B, based on the method of Example Clause A, wherein a threshold number of interruptions is defined within a predetermined time period, and tracking is implemented during that predetermined time period.

[0073] Example Clause C, based on the method of Example Clause B, wherein a threshold number of interruptions is statically defined within a predetermined time period.

[0074] Example Clause D, based on the method of Example Clause B, wherein the threshold number of interruptions is dynamically defined within a predetermined time period.

[0075] Example clause E, according to any one of example clauses A through D, wherein the firmware agent includes a baseboard management controller.

[0076] Example Clause F, according to the method of Example Clause E, wherein the baseboard management controller is configured to enable interrupts that switch the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode by toggling a general purpose input / output pin.

[0077] Example clause G, according to the method of any one of example clauses A through F, wherein a threshold number of interrupts is defined for a particular type of interrupt, and the method further includes storing the threshold number of interrupts defined for the particular type of interrupt in a table.

[0078] Example clause H, in accordance with the method of example clause G, further includes: defining, for other corresponding types of interrupts, the number of additional thresholds for interrupts that allow the central processing unit to switch its operating mode from real operating mode or protected operating mode to system management operating mode; and storing the number of additional thresholds for interrupts defined for other corresponding types of interrupts in a table.

[0079] Example Clause I, according to the method of Example Clause H, wherein the type of interrupt is mapped to an entry in a table based on the interface that receives the interrupt call request.

[0080] Example Clause J, a method implemented by a firmware agent for limiting the number of unauthorized interrupts that switch the operating mode of a central processing unit (CPU) from a real operating mode or a protected operating mode to a system management operating mode, includes: defining a threshold number of interrupts allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode; receiving a first interrupt invocation request; determining that the current number of interrupts allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode does not meet the threshold number of interrupts; and responding to the determination that the current number of interrupts allowed to switch the CPU's operating mode from a real operating mode or a protected operating mode to a system management operating mode is insufficient. The system executes the following steps: if the current number of interrupts does not meet the interrupt threshold, it invokes a first interrupt based on a first interrupt call request, the first interrupt switching the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode; it increments the current number of interrupts by 1; it receives a second interrupt call request; it determines that the current number of interrupts that have been allowed to switch the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode meets the interrupt threshold; and in response to determining that the current number of currently tracked interrupts that have been allowed to switch the operating mode of the central processing unit from real operating mode or protected operating mode to system management operating mode meets the interrupt threshold, it prevents the invocation of a second interrupt based on the second interrupt call request.

[0081] Example clause K, following the method of example clause J, defines a threshold number of interruptions within a predetermined time period, and resets the current number of interruptions to zero when the predetermined time period expires.

[0082] Example clause L, based on the method of example clause K, wherein a threshold number of interruptions is statically defined within a predetermined time period.

[0083] Example clause M, based on the method of example clause K, wherein the threshold number of interruptions is dynamically defined within a predetermined time period.

[0084] Example Clause N, according to any one of Example Clauses J to M, wherein the firmware agent includes a baseboard management controller.

[0085] Example Clause O, according to the method of Example Clause N, wherein the baseboard management controller is configured to invoke a first interrupt via toggling a general purpose input / output pin.

[0086] Example clause P, according to any one of example clauses J to O, wherein a threshold number of interrupts is defined for a particular type of interrupt, and the method further includes storing the threshold number of interrupts defined for the particular type of interrupt in a table.

[0087] Example Clause Q, a baseboard management controller configured to perform operations including: tracking the number of interrupts that have been allowed to switch the operating mode of the central processing unit from a real operating mode or a protected operating mode to a system management operating mode; based on the tracking, determining that the number of interrupts has met a threshold number of interrupts; and based on the determination, preventing additional interrupts from being allowed to switch the operating mode of the central processing unit from a real operating mode or a protected operating mode to a system management operating mode.

[0088] Example clause R, a baseboard management controller according to example clause Q, wherein a threshold number of interruptions is defined within a predetermined time period, and tracking is implemented during that predetermined time period.

[0089] Example Clause S, a baseboard management controller according to Example Clause Q or Example Clause R, wherein a threshold number of interrupts is defined for a specific type of interrupt, and the operation also includes storing the threshold number of interrupts defined for the specific type of interrupt in a table.

[0090] Example Clause T, the baseboard management controller according to Example Clause S, wherein the operation further includes: defining, for other corresponding types of interrupts, an additional number of interrupt thresholds that allow the central processing unit's operating mode to switch from real operating mode or protected operating mode to system management operating mode; and storing the additional number of interrupt thresholds defined for other corresponding types of interrupts in a table.

[0091] Unless otherwise specifically stated, conditional language (such as "can / could / might / may") should be understood in context as indicating that some examples include (while others do not) certain features, elements, and / or steps. Therefore, such conditional language is generally not intended to imply that certain features, elements, and / or steps are necessary in any way for one or more examples, or that one or more examples necessarily include logic for determining whether to include or perform certain features, elements, and / or steps in any particular example, with or without user input or prompts. Unless otherwise specifically stated, conjunctional language (such as the phrase "at least one of X, Y, or Z") should be understood as indicating that items, terms, etc., can be X, Y, or Z, or combinations thereof.

[0092] Unless otherwise indicated herein or clearly contradicted by the context, the terms “a / an,” “the,” and similar references used in the context of describing the invention (particularly in the context of the appended claims) shall be construed as encompassing both the singular and plural forms. Unless otherwise indicated or clearly contradicted by the context, the terms “based on,” “based upon,” and similar references shall be construed as meaning “at least partially based,” including both “partially based” and “fully based.”

[0093] It should be understood that any reference to elements such as “first” and “second” in the summary and / or detailed description is not intended and should not be construed as necessarily corresponding to any reference to elements such as “first” and “second” in the claims. Rather, any use of “first” and “second” in the summary, detailed description, and / or claims may be used to distinguish two different instances of the same element (e.g., two different types, two different requests, etc.).

[0094] Finally, although various configurations have been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended statements is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claimed subject matter. All examples are provided for illustrative purposes and should not be construed as restrictive.

Claims

1. A method implemented by a firmware agent (114) for limiting the number of unauthorized interrupts (130) that switch the operating mode of a central processing unit (104) from a real operating mode (108) or a protected operating mode (110) to a system management operating mode (112), comprising: Definition (402) is the number of interrupt thresholds (132) that allow the central processing unit to switch its operating mode from the real operating mode or the protected operating mode to the system management operating mode; The tracking (404) has been enabled for the number of interrupts (214) that allow the central processing unit to switch its operating mode from the real operating mode or the protected operating mode to the system management operating mode; Based on the tracking, it is determined (406) that the number of interruptions has met the threshold number of interruptions; as well as Based on the determination, blocking (408) the additional interrupt (242) is allowed to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode.

2. The method of claim 1, wherein the threshold number of interruptions is defined for a predetermined time period, and the tracking is performed during the predetermined time period.

3. The method of claim 2, wherein the threshold number of interruptions is statically defined for the predetermined time period.

4. The method of claim 2, wherein the number of interruptions is dynamically defined for the predetermined time period.

5. The method according to any one of claims 1 to 4, wherein the firmware agent includes a baseboard management controller.

6. The method of claim 5, wherein the baseboard management controller is configured to allow interrupts to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode via a toggle of a general-purpose input / output pin.

7. The method of any one of claims 1 to 6, wherein the threshold number of interrupts is defined for a specific type of interrupt, and the method further comprises storing the threshold number of interrupts defined for the specific type of interrupt in a table.

8. The method according to claim 7, further comprising: For other corresponding types of interrupts, define other threshold numbers of interrupts that allow the central processing unit to switch its operating mode from the real operating mode or the protected operating mode to the system management operating mode; as well as The number of additional thresholds for the interrupts defined for the other corresponding types of interrupts is stored in the table.

9. The method of claim 8, wherein the type of interrupt is mapped to an entry in the table based on the interface that receives the interrupt call request.

10. A method implemented by a firmware agent (114) for limiting the number of unauthorized interrupts (130) that switch the operating mode of a central processing unit (104) from a real operating mode (108) or a protected operating mode (110) to a system management operating mode (112), comprising: Definition (502) is the number of interrupts (132) that allow the central processing unit to switch its operating mode from the real operating mode or the protected operating mode to the system management operating mode. Receive (504) first interrupt call request (220(2)); The current number (214) of interrupts that have been allowed to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode does not meet the threshold number of interrupts. In response to the determination that the current number of interrupts that have been allowed to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode does not meet the threshold number of interrupts, a first interrupt (226) is invoked (508) based on the first interrupt invocation request, the first interrupt switching the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode. Increment the current number of interruptions by (510) - (228); Receive (502) second interrupt call request (240(2)); The current number of interrupts that have been determined (504) to allow switching the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode meets the threshold number of interrupts. as well as In response to determining that the number of currently tracked interrupts that have been allowed to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode meets the threshold number of interrupts, the second interrupt is prevented (512) from being invoked based on the second interrupt call request (242).

11. The method of claim 10, wherein the threshold number of interruptions is defined for a predetermined time period, and the current number of interruptions is reset to zero after the predetermined time period expires.

12. The method of claim 11, wherein the number of interruptions is statically defined for the predetermined time period.

13. The method of claim 11, wherein the number of interruptions is dynamically defined for the predetermined time period.

14. The method according to any one of claims 10 to 13, wherein the firmware agent includes a baseboard management controller.

15. The method of claim 14, wherein the substrate management controller is configured to invoke the first interrupt via a toggling of a general purpose input / output pin.

16. The method of any one of claims 10 to 15, wherein the threshold number of interrupts is defined for a specific type of interrupt, and the method further comprises storing the threshold number of interrupts defined for the specific type of interrupt in a table.

17. A substrate management controller (240) configured to perform operations including: The number of interrupts (214) that have been allowed to switch the operating mode of the central processing unit (104) from the real operating mode (108) or the protected operating mode (110) to the system management operating mode (112) has been tracked (404); Based on the tracking, it is determined (406) that the number of interruptions has met the threshold number of interruptions (132); as well as Based on the determination, blocking (408) the additional interrupt (242) is allowed to switch the operating mode of the central processing unit from the real operating mode or the protected operating mode to the system management operating mode.

18. The baseboard management controller of claim 17, wherein the number of interruption thresholds is defined for a predetermined time period, and the tracking is performed during the predetermined time period.

19. The baseboard management controller of claim 17 or claim 18, wherein the number of interrupts is defined for a specific type of interrupt, and the operation further includes storing the number of interrupts defined for the specific type of interrupt in a table.

20. The baseboard management controller of claim 19, wherein the operation further comprises: For other corresponding types of interrupts, define other threshold numbers of interrupts that allow the central processing unit to switch its operating mode from the real operating mode or the protected operating mode to the system management operating mode; as well as The number of additional thresholds for the interrupts defined for the other corresponding types of interrupts is stored in the table.

Images