Method and apparatus for anti-fallback protection for non-persistent software

Abstract

A method and apparatus for anti-fallback protection of non-persistent software in a system. The software installation package comprises a main version of the software and a backup version of the software. The backup version of the software includes a list of vulnerable versions that includes a series of vulnerable versions of the software determined up to a release date of the backup version of the software. A backup version of the software is stored in the system. If the main version of the software is not listed in the list of vulnerable versions, the main version of the software is installed. If a new backup version higher than the existing backup version is received, the backup version may be automatically updated. The backup version is stored in a backup version repository by the operating system or installer. The backup version may include a list of allowed versions.

Description

BACKGROUND OF THE INVENTION

[0001] Many hardware (HW) components or software (SW) applications use non-persistent firmware (FW) that is loaded by their SW drivers, SW tools, or installers at boot time, during the initialization phase (when first used), or as needed. Non-persistent FW can be considered an extended SW part running on a HW device. If the non-persistent FW has been compromised or tampered with (e.g., through an exploitable vulnerability), it may allow an attacker to elevate their privileges from the SW or system to that FW and, through lateral movement, to other firmware intellectual property (IP) or hardware blocks. This type of FW is also a good place to hide malicious code execution or even execute malicious code. Since it is not executable by a conventional operating system (OS) and is loaded in HW IP that can affect the platform and OS, antivirus and endpoint detection and response (EDR) may not be able to detect this type of FW. Currently, there is no good solution to prevent such FW, SW, or drivers from reverting to a vulnerable previous version. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some examples of the apparatus and / or method will be described below only by way of example and with reference to the accompanying drawings, in which:

[0003] Figure 1 is a schematic diagram of an apparatus for anti-rollback protection of persistent SW / FW;

[0004] Figure 2 is an example signal flow diagram of anti-rollback protection against rollback attacks according to the example solution disclosed herein;

[0005] Figure 3 is a flowchart of an example process for anti-rollback protection of non-persistent software in a system;

[0006] Figure 4 is a flowchart of an example process for anti-rollback protection of non-persistent software in a system;

[0007] Figure 5 is a block diagram of an electronic device including at least one of the electronic components and / or methods described herein;

[0008] Figure 6 illustrates a computing device according to one implementation of the present invention; and

[0009] Figure 7Are included to show examples of higher-level device applications for the disclosed embodiments. Detailed Description

[0010] The examples will now be described more fully with reference to the accompanying drawings, in which some examples are illustrated. In the drawings, for clarity, the thickness of lines, layers, and / or regions may be exaggerated.

[0011] Accordingly, although further examples may have various modifications and alternative forms, some specific examples thereof are shown in the drawings and will subsequently be described in detail. However, such detailed description is not intended to limit further examples to the particular forms described. Further examples may cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure. Throughout the description of the drawings, the same numbers refer to the same or similar elements, which may be implemented identically to or in a modified form relative to each other while providing the same or similar functions.

[0012] It will be understood that when an element is referred to as being "connected to" or "coupled to" another element, these elements may be directly connected or coupled or connected or coupled via one or more intervening elements. If two elements A and B are combined using "or", it is to be understood that all possible combinations are disclosed, i.e., only A, only B, and A and B. An alternative phrase for the same combination is "at least one of A and B". This also applies to combinations of more than two elements.

[0013] The terms used herein for the purpose of describing particular examples are not intended to limit further examples. Whenever the singular forms (such as "a / an" and "the") are used and the use of only a single element is neither explicitly nor implicitly defined as mandatory, further examples may also be implemented using plural elements to achieve the same function. Similarly, when a function is subsequently described as being implemented using multiple elements, further examples may be implemented using a single element or processing entity to achieve the same function. It will also be understood that when the terms "comprise and / or comprising", "include and / or including" are used, they specify the presence of the stated features, integers, steps, operations, processes, actions, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, processes, actions, elements, components, and / or groups thereof.

[0014] Unless otherwise defined, all terms (including technical and scientific terms) are used herein in their ordinary meaning in the field to which the examples belong.

[0015] In the following description, specific details are set forth, but examples of the techniques described herein may be practiced without these specific details. Well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this description. "Example", "each example", "some examples", etc. may include features, structures, or characteristics, but not every example necessarily includes these specific features, structures, or characteristics.

[0016] Some examples may have some or all of the features described for other examples, or none of these features at all. "First", "second", "third", etc. describe common elements and indicate different instances of the same element being referenced. Such adjectives do not imply that the elements so described must be in a given order in time or space, in ranking, or in any other way. "Connected" may indicate that elements are in direct physical or electrical contact with each other, and "coupled" may indicate that elements cooperate or interact with each other, but these elements may or may not be in direct physical or electrical contact.

[0017] As used herein, the terms "operate", "execute", or "run" may be used interchangeably when referring to software or firmware related to a system, device, platform, or resource, and may refer to software or firmware stored in one or more computer-readable storage media accessible by the system, device, platform, or resource, even if the instructions contained in the software or firmware are not being actively executed by the system, device, platform, or resource.

[0018] The specification may use the phrases "in one example", "in an example", "in some examples", and / or "in each example", each of which may refer to one or more of the same or different examples. Additionally, the terms "comprising", "including", "having", etc. are synonymous as used with respect to the examples of the present disclosure.

[0019] Non-persistent SW or FW can be installed and reinstalled as needed or via a mechanism controlled by the user (e.g., after each reboot, etc.). Non-persistent SW / FW is SW / FW that can be automatically installed, reinstalled, or uninstalled by the user or through a predefined mechanism controlled by the user, SW provider, original equipment manufacturer (OEM), original design manufacturer (ODM), etc. A driver, SW tool, or installer can load the non-persistent SW / FW as needed before its use. A rollback to a previous version of the SW / FW may be performed. Currently, there is no anti-rollback (ARB) mechanism for non-persistent SW / FW because the user can control at the OS level which version of the SW / FW is installed, and for the sake of usability and system functionality, the OS or its delivery mechanism allows downgrading to a lower version of the SW / FW. Anti-rollback is contradictory to system usability and system functionality. If one is fully implemented today, the other will be affected. An attacker can take advantage of this to download a malicious (previous) version of the SW / FW and then abuse the system.

[0020] In the Windows OS, there is a possibility of anti-rollback of the driver through certificate revocation of the driver (including FW). Such a mechanism requires connectivity to the OS vendor's DB and cannot be implemented in an isolated system. Certificate revocation will reject driver installation / loading and bundled FW updates. If the certificate is in the revocation list managed by the OS provider, the driver will not be loaded. Since the revoked driver will no longer function, if such a mechanism is used, it will result in the loss of critical functions in the system. The implemented mechanism is partially used due to usability and functionality impacts.

[0021] Alternatively, secure boot with the concept of a signed "monolithic image" can be used. The driver is compiled as part of the kernel and is not loadable, and the driver cannot be updated without an update of the entire kernel image if there is no control over image loading (e.g., Chrome OS). As long as secure boot is enabled, the signed image is good, and the FW / SW of the driver will not be tampered with after secure boot. The vendor decides which image is the most recent and secure, and will not continuously release new versions for a specific SW / FW / driver. Android from an approved market only allows the most recent version.

[0022] Alternatively, the FW can be made persistent and updated only with approved versions, controlled by a BootROM - type mechanism. This will always maintain a valid FW version on the persistent device storage. However, not all IPs benefit from the persistent storage due to increased bill of material (BoM) or other constraints. This solution does not address non - persistent use cases.

[0023] Fall - back prevention consists of two steps: detection of vulnerable fall - back SW / FW versions and a fall - back mechanism to a secure SW / FW version. In an example, the delivery mechanism (e.g., the operating system) maintains a back - up version of the SW / FW package to be installed or updated, and in the case where the proposed SW / FW version is determined to be vulnerable, the delivery mechanism will reject the installation or update and can automatically revert to the back - up version of the SW / FW.

[0024] Currently, there is no such mechanism at the SW level. According to the example scenarios disclosed herein, fall - back protection can be provided for SW / FW packages, and users can benefit from better security. The example scenarios disclosed herein are applicable to any system that lacks persistent memory and loads the FW / SW whenever the FW / SW is called, activated, or used. The example scenarios disclosed herein are applicable to any system that supports SW / FW fall - back, either based on user decisions or automatically, to maintain user interfaces or legacy functionality. The example scenarios disclosed herein can work online or offline. The example scenarios disclosed herein can work in an offline system where there is no option to obtain automatic updates and the system owner cannot rely on automatic SW / FW updates to keep the system up - to - date. The example scenarios disclosed herein provide better security and are consistent with security safeguards, i.e., adding a new layer of protection that is not currently available.

[0025] Examples of fall - back protection for persistent SW / FW will be explained below. Figure 1Schematic diagram of a device for anti-rollback protection for persistent SW / FW. Hereinafter, the term "SW" will be used to include "FW". Device 100 includes processing circuitry 110 and a storage device 120. The processing circuitry 110 may be configured to receive a software installation package. The software installation package includes a primary version of the software and a fallback version of the software. In an example, each SW installation package includes a fallback version in addition to the primary version. Each installed SW package has a fallback version. In the event that a vulnerability is detected in the existing SW version, the fallback version of the SW is used for rollback. The fallback version of the software includes a list of vulnerable versions, which includes a series of vulnerable versions of the software determined as of the release date of the fallback version of the software. The storage device 120 may be configured to store the fallback version of the software. The processing circuitry 110 may be configured to: install the primary version of the software if the primary version of the software is not included in the list of vulnerable versions.

[0026] The processing circuitry 110 may be configured to receive a second software installation package for upgrade or downgrade. The second software installation package includes a second primary version of the software and a second fallback version of the software. The second fallback version of the software includes a second list of vulnerable versions, which includes a series of vulnerable versions of the software determined as of the release date of the second fallback version of the software. The second fallback version may be the same as or different from the first fallback version. The processing circuitry 110 may be configured to: update the fallback version of the software stored in the system if the second fallback version of the software is a higher version than the fallback version of the software stored in the system; and make no change to the fallback version of the software stored in the system if the second fallback version of the software is not a higher version than the fallback version of the software stored in the system.

[0027] The processing circuitry 110 may be configured to: install the second primary version of the software if the second primary version of the software is not included in the list of vulnerable versions, which is included in the fallback version of the higher version, stored in the system or received in the new package, and the processing circuitry 110 may be configured to: not install the second primary version of the software if the second primary version of the software is included in the list of vulnerable versions. Alternatively, the processing circuitry 110 may be configured to: install the fallback version of the software if the primary version of the software is included in the list of vulnerable versions.

[0028] The processing circuitry 110 may be configured to uninstall the primary version of the software. In this case, after uninstalling the primary version of the software, the fallback version remains in the system without any change.

[0029] A fallback version of the software can be stored in a fallback version repository in the storage device 120 by the operating system or by a delivery mechanism. In some examples, the fallback version of the software can be stored in a secure storage device in the form of hardware or in a secure storage device at a registry hive protected by the operating system.

[0030] In some examples, the fallback version of the software can also include a list of allowed versions indicating the (one or more) versions of the software that are allowed to be installed. In such a case, the processing circuitry 110 can be configured to install the primary version of the software only if the primary version of the software is included in the list of allowed versions.

[0031] In some examples, the software installation package can be signed with a digital signature, and the primary version of the software and the fallback version of the software can also be each signed with a separate digital signature. The processing circuitry 110 can be configured to: if the software installation package, the primary version of the software, and the fallback version of the software are all verified by their respective digital signatures, install the primary version of the software and store the fallback version in the system.

[0032] Examples of anti-rollback protection for non-persistent SW / FW will be explained in detail below. The examples disclosed herein can be explained with reference to the SW, the driver, or the installer responsible for SW / FW updates, but can be extended to any SW package. An SW package includes a collection of software programs that are bundled together and can also include an installer for installing these software programs. In an example, each SW / FW installation package includes a primary version (i.e., the desired version) of the SW / FW package and a fallback version of the SW / FW. Both of these versions (i.e., the desired version and the fallback version) are embedded in a single SW / FW installation package. In the case where vulnerability is detected in an existing SW / FW version, the fallback version of the SW / FW is used for rollback. The fallback version may include limited functionality compared to the primary version. The fallback version included in the same SW package may be of the same generation as the primary version. The example solution disclosed herein does not rely on a centralized repository and can work with or without a network connection. The example solution disclosed herein can be applied to any OS, including Windows OS, Linux, Chrome, or any other operating system.

[0033] In addition, the fallback versions of the SW / FW included in each SW / FW installation package include a list of vulnerable versions. The list of vulnerable versions may be metadata included in the fallback version. The list of vulnerable versions includes / indicates all the vulnerable versions of the SW / FW that have been detected as of the date the fallback version was released. The SW vendor will release a new fallback version when it releases a new fix for an existing vulnerable version of the SW / FW. The list of vulnerable versions will include all the new vulnerable versions in the field. The list of vulnerable versions can be updated by an updated fallback version.

[0034] If a new version of the SW / FW is installed in the system, the new SW / FW installation package may include a new fallback version with an updated list of vulnerable versions. In such a case, the user will not be able to downgrade to a vulnerable fallback version as long as the entire system is not rebuilt. The fallback version cannot be rolled back to a lower fallback version but can only be upgraded to a higher version. If a new fallback version is available for update in the system, the system updates the new fallback version manually or automatically. The system according to the examples disclosed herein only allows the process towards a more secure version (fallback version) of the SW / FW and will not reduce the system security inadvertently or intentionally by an attacker.

[0035] The SW / FW installation package may include a digital signature. The digital signature is applied to the software binary or file. The digital signature confirms the identity of the software author or publisher and verifies that the file has not been changed or tampered with since the digital signature was signed. The SW / FW package with a valid digital signature ensures that the SW / FW package has not been modified or changed since the digital signature was applied to the SW / FW package. By using a digitally signed SW / FW package, the SW / FW package can be safely downloaded and added to the system because the digital signature can be verified before the SW / FW package is added to the system. In the example, the SW / FW package including the main version and the fallback version can be signed digitally. Additionally, each part of the main version and the fallback version can be signed digitally separately so that the integrity and authenticity of the SW / FW installation package and each part of the main version and the fallback version can be verified and confirmed. For example, the digitally signed SW / FW package may contain (SW|FW package + unique version) (signed) and (SW|FW fallback package + unique version + list of vulnerable versions) (signed).

[0036] In an example, a fallback version of the SW / FW received via an SW / FW installation package is stored in a fallback version repository (ARB repository) in the system. In one example, the OS can manage the SW / FW package availability. In such a case, the OS is relied upon to manage the fallback version repository. Alternatively, the fallback version repository can be managed without relying on the OS. In such a case, a secure storage device (e.g., an HW-based storage device) can be used to hold the fallback version of each installed SW / FW package.

[0037] In one example, the OS of the system can manage the SW / FW installation package availability. The OS vendor may want to maintain system availability even if a user inadvertently or deliberately attempts to downgrade the system to a vulnerable version. Once the SW / FW package is installed in the system by the OS or its delivery mechanism (e.g., installer, driver, etc.), the fallback version of the SW / FW is stored in the fallback version repository and remains in the system until the OS is reinstalled from scratch (rather than upgraded). The fallback version of the SW / FW can be updated manually or via an automatic update if the system supports automatic updates.

[0038] For the first installation of the SW / FW, a specific version of the SW / FW installation package will be received by the system (device). The SW / FW installation package includes a primary version and a fallback version, and the fallback version includes a list of vulnerable versions. The fallback version of the SW / FW included in the SW / FW installation package is added to the fallback version repository by the delivery mechanism or the system (e.g., the OS). The fallback version includes a list of vulnerable versions. The list of vulnerable versions includes / indicates all vulnerable versions of the SW / FW as of the release date of the fallback version. If the primary version of the received SW / FW installation package is determined to be secure (not vulnerable) (e.g., the list of vulnerable versions does not include the primary version), then the primary version is installed. If the primary version of the received SW / FW installation package is determined to be vulnerable (e.g., the list of vulnerable versions includes the primary version), then the primary version is not installed, and instead, the fallback version can be installed (e.g., depending on the user's input). For the first installation, the system will only store the fallback version. For subsequent updates, the fallback version will only be updated if the received fallback version is more recent than the fallback version stored in the system.

[0039] The SW / FW vendor will digitally sign the SW / FW package and each part of the package (i.e., the main version and the fallback version) separately in a digital manner, and will provide the OS vendor with the fallback version of the SW / FW. The SW / FW vendor will be able to update the OS vendor with a new and more secure fallback version of the SW / FW and versions that should be revoked due to security reasons. For example, the SW / FW vendor may revoke those vulnerable versions of the SW / FW based on a certificate revocation mechanism or any other revocation mechanism supported by the OS vendor. Thus, for the first installation of the SW / FW package, the delivery mechanism at the OS level may only load the SW / FW version that is digitally signed, verified, and not revoked, and the vulnerable versions may be rejected through the certificate revocation of the delivery mechanism or an alternative mechanism supported by the OS.

[0040] In the case of uninstalling the existing SW / FW, only the active version of the SW / FW on the system is removed, and the fallback version remains intact in the system for future use.

[0041] For the upgrade of the SW / FW, the system receives the SW / FW installation package for the upgraded version. The new SW / FW installation package includes the upgraded main version of the SW / FW and the fallback version. If the fallback version included in the new SW / FW installation package for the upgraded version is newer (higher) than the fallback version stored in the system, the fallback version is updated manually or automatically. If the fallback version included in the new SW / FW installation package for the upgraded version has the same version as the existing fallback version stored in the system, no change is made to the existing fallback version in the system.

[0042] The system then checks whether the upgraded main version of the SW / FW is vulnerable. The vulnerability of the new main version can be determined by checking the list of vulnerable versions included in the new fallback version (or the existing fallback version if the fallback version is not updated). If the upgraded main version is determined not to be vulnerable (e.g., the upgraded main version is not included in the list of vulnerable versions), the upgraded main version is installed. If the upgraded main version is determined to be vulnerable (e.g., the upgraded main version is included in the list of vulnerable versions), the upgraded main version is not installed (i.e., the upgrade is not performed).

[0043] For downgrading of the SW / FW, the system receives another SW / FW installation package for a lower version of the SW / FW. The SW / FW installation package includes a downgraded major version of the SW / FW and a fallback version of the SW / FW. The system checks whether the downgraded major version of the SW / FW is vulnerable. The vulnerability of the downgraded major version can be determined by checking the list of vulnerable versions included in the fallback version stored in the system (or the fallback version received in the new SW / FW installation package if the received version is higher).

[0044] If the downgraded major version is determined to not be vulnerable (e.g., the downgraded major version is not included in the list of vulnerable versions), then the downgraded major version is installed. If the downgraded major version is determined to be vulnerable (e.g., the downgraded major version is included in the list of vulnerable versions), then the downgraded major version is not installed (i.e., the downgrade fails). In such a case, the system may maintain the existing version or may install the fallback version (e.g., depending on user input). When the downgraded version of the package has the same or a lower fallback version, the existing fallback version can remain intact.

[0045] Example scenarios of SW installation, upgrade, and downgrade are explained below. The SW package can have a version in the main.minor format (e.g., 1.2, 3.4, 20.10).

[0046] Example 1.

[0047] For the first installation of the SW, the system receives the following SW installation package: SW installation package version 5.3: major version 5.3 + fallback version 5.3 including a list of vulnerable versions (5.2, 5.1, 5.0, 4.1, 4.5, 3.4, 3.3, 2.1). In this case, since version 5.3 is not in the list of vulnerable versions, assuming the integrity of the package and each part of the major version and fallback version has been verified by digital signature, the major version 5.3 will be successfully installed. The fallback version 5.3 will be saved in the fallback version repository.

[0048] Subsequently, the system attempts to downgrade to version 4.3. The system receives the following SW installation package: SW installation package version 4.3: major version 4.3 + fallback version 4.3 including a list of vulnerable versions (4.1, 4.2, 3.4, 3.3, 2.1). In this case, since major version 4.3 is not in the list of vulnerable versions included in fallback version 5.3 (the fallback version currently stored in the system), major version 4.3 will be successfully installed. Since the fallback version stored in the system (fallback version 5.3) is a higher version, this fallback version remains unchanged and is kept in the fallback version repository.

[0049] Subsequently, the system attempts to upgrade to version 4.5. The system receives the following SW installation package: SW installation package version 4.5: Major version 4.5 + fallback version 4.5 including a list of vulnerable versions (4.1, 4.2, 3.4, 3.3, 2.1). In this case, since major version 4.5 is included in the list of vulnerable versions currently stored in the system (i.e., the list of vulnerable versions included in fallback version 5.3), the upgrade to major version 4.5 will fail. Instead of installing major version 4.5, the system can install fallback version 5.3 or remain at the current major version 4.3 (e.g., based on user input).

[0050] Example 2.

[0051] For the first installation of the SW, the system receives the following SW installation package: SW installation package version 4.3: Major version 4.3 + fallback version 4.3 including a list of vulnerable versions (4.1, 4.2, 3.4, 3.3, 2.1). In this case, since version 4.3 is not in the list of vulnerable versions, assuming the integrity of each part of package 4.3 as well as the major and fallback versions has been verified by digital signature, major version 4.3 will be successfully installed. The fallback version 4.3 will be saved in the fallback version repository.

[0052] Subsequently, for the upgrade to version 4.5, the system receives the following new SW installation package: SW installation package version 4.5: Major version 4.5 + fallback version 4.5 including a list of vulnerable versions (4.1, 4.2, 4.3, 3.4, 3.3, 2.1). In this case, since major version 4.5 is not in the list of vulnerable versions (i.e., the updated list of vulnerable versions received in package version 4.5), major version 4.5 will be successfully installed. Since the fallback version 4.5 is a newer version, the fallback version will also be upgraded to fallback version 4.5. The system keeps the new fallback version 4.5 including the new list of vulnerable versions.

[0053] Subsequently, for the downgrade to version 4.3, the system receives the following another SW installation package: SW Installation Package Version 4.3: The major version 4.3+ includes the fallback version 4.3 for the list of vulnerable versions (4.1, 4.2, 3.4, 3.3, 2.1). In this case, since the major version 4.3 is now included in the list of vulnerable versions currently stored in the system (i.e., the list of vulnerable versions included in the fallback version 4.5), the downgrade to the major version 4.3 will fail. Since the fallback version 4.5 is a higher version, the fallback version is not updated. After the downgrade fails, the system can install the fallback version 4.5 or can keep the major version 4.5 (e.g., based on the user's input).

[0054] In another example, a secure storage device in the system (e.g., an HW-based storage device) can be used to hold the fallback versions of each installed SW / FW package. In cases where the OS cannot be relied upon to manage the fallback version repository, a secure storage device in the hardware of the system or at a registry hive protected by the OS can be used to store the fallback versions. A registry hive protected by the OS can be a hierarchical database used by the OS to store configuration settings, options, etc. In this example, the SW / FW installer controls the management of the fallback versions. The SW / FW installer can register the fallback versions in the secure storage device in the system. This can be done since the delivery mechanism will check the digital signatures of the entire SW / FW package and the digital signatures of the fallback versions and will check if the existing SW / FW package has been registered. In the case of a first installation, the system will only store the fallback version, and for subsequent updates, the fallback version will only be updated if the fallback version is newer than the fallback version stored in the system.

[0055] Once the SW / FW package is installed in the system by the OS or by its delivery mechanism (e.g., installer, driver, etc.), the fallback version will remain in the system until the OS is reinstalled from scratch (rather than upgraded), or if stored in HW, the fallback version will remain in the system forever. It is assumed that the fallback version can be updated manually or, in cases where the system supports automatic updates, by automatic updates.

[0056] For the first installation of SW / FW, a specific version of the SW / FW installation package will be received by the system. The SW / FW installation package includes a primary version and a fallback version, and the fallback version includes a list of vulnerable versions. The fallback version of the SW / FW included in the SW / FW installation package is added to the fallback version repository by the delivery mechanism or the system. The fallback version includes a list of vulnerable versions. The list of vulnerable versions is metadata included in the fallback version of the SW / FW. The list of vulnerable versions includes all vulnerable versions of the SW / FW as of the release date of the fallback version. If the primary version of the received SW / FW installation package is determined to be secure (not vulnerable) (e.g., the list of vulnerable versions does not include the primary version), then the primary version is installed. If the primary version of the received SW / FW installation package is determined to be vulnerable (e.g., the list of vulnerable versions includes the primary version), then the primary version is not installed, and instead, the fallback version may be installed. For the first installation of the SW / FW package, the delivery mechanism at the OS level can only load SW / FW versions that are digitally signed, verified, and not revoked, and vulnerable versions can be rejected through certificate revocation or alternative mechanisms supported by the OS.

[0057] For the uninstallation of existing SW / FW, only the active version on the system is removed, and the fallback version remains intact in the system for future use. In the case where a malicious user manually removes SW / FW from the system, the malicious user may not be able to update to any vulnerable version listed in the list of vulnerable versions maintained in the HW or OS registry (i.e., the HW can also protect against SW system attackers, while the OS registry only protects against non-system attackers).

[0058] For the upgrade of SW / FW, the system receives an installation package for the upgraded / higher version of the SW / FW. The new SW / FW installation package includes the upgraded primary version of the SW / FW and a new fallback version. If the new fallback version included in the SW / FW installation package for the upgraded version is newer (higher) than the existing fallback version in the system, then the fallback version is updated manually or automatically. If the fallback version included in the new SW / FW installation package for the upgraded version has the same version as the existing fallback version or is lower than the existing fallback version, then no change is made to the fallback version stored in the system.

[0059] The system then checks whether the upgraded major version of the SW / FW is vulnerable. The vulnerability of the new major version can be determined by checking the list of vulnerable versions included in the new fallback version (or, if the fallback version has not been updated, the existing fallback version). If the upgraded major version is determined to be not vulnerable (e.g., the upgraded major version is not included in the list of vulnerable versions), then the upgraded major version is installed. If the upgraded major version is determined to be vulnerable (e.g., the upgraded major version is included in the list of vulnerable versions), then the upgraded major version is not installed (i.e., the upgrade is not performed).

[0060] For downgrading of the SW / FW, the system receives another SW / FW installation package for a lower version. The SW / FW installation package includes the downgraded major version of the SW / FW and the fallback version of the SW / FW. The system checks whether the downgraded major version of the SW / FW is vulnerable. The vulnerability of the downgraded major version can be determined by checking the list of vulnerable versions included in the fallback version stored in the system (or, if the received version is higher, the fallback version received in the new SW / FW installation package).

[0061] If the downgraded major version is determined to be not vulnerable (e.g., the downgraded major version is not included in the list of vulnerable versions), then the downgraded major version is installed. If the downgraded major version is determined to be vulnerable (e.g., the downgraded major version is included in the list of vulnerable versions), then the downgraded major version is not installed (i.e., the downgrade fails). In such a case, the system can maintain the existing version or can install the fallback version (e.g., depending on the user input). If the downgraded version has the same or a lower fallback version, the existing fallback version can remain intact.

[0062] In the example scenario disclosed herein, the SW / FW delivery mechanism (e.g., SW driver, installation tool, etc.) will not be able to load a vulnerable SW / FW image because the revoked version of the SW / FW will be detected by the OS via the list of vulnerable versions as explained above and will not be updated or installed. In the example mechanism disclosed herein, if a vulnerable SW / FW version is detected, the OS can use the fallback version of the SW / FW available to the OS to resume the installation / update process.

[0063] In the example, the fallback version of the SW image will be secure and can provide full or partially required functionality depending on the use case. The system according to the example scenario disclosed herein will provide both security and UX / availability.

[0064] Figure 2It is an example signal flow diagram of fallback protection against fallback attacks according to the example solutions disclosed herein. Assume that SW version X+1 is currently installed on the system, and this SW version X+1 is a good (not vulnerable) version of the SW. An attacker attempts to uninstall the good version (version X+1) of the SW (202) and load an old vulnerable version (version X) of the SW (204).

[0065] The OS checks whether version X of the SW has been revoked (i.e., whether version X is included in the vulnerable list currently stored in the system) (206). If it is determined that version X has been revoked (i.e., version X is included in the vulnerable version list), the OS starts the recovery to the fallback version (208). The OS requests the installation of the fallback version from the drive (210), and the drive downloads and installs the fallback version (212). The OS can notify the user of the installation of the restricted version (fallback version) of the SW instead of the updated version (version X+1) (214).

[0066] In the case of persistent FW, the FW delivery mechanism updates the existing FW (update process). For recovery to a secure version, the update will fail, and the system remains with the existing FW. In the case of non-persistent FW, the FW delivery mechanism loads a new FW (initiate / start). For recovery to a secure version, the conventional solution is to prevent FW loading, which results in the loss of critical desired functionality. In contrast, according to the examples disclosed herein, the FW update / install will fail, and the system reverts to the fallback version.

[0067] As disclosed above, the fallback version includes a vulnerable version list. In some examples, in addition to the vulnerable version list, the fallback version may also include an allowed version list as metadata. The allowed version list indicates the SW / FW versions that are allowed for installation or update. If the allowed version list is included in the fallback version, the system can only downgrade to the versions included in the allowed version list. Whether to include the allowed version list may depend on the policy. The allowed version list may be included in the fallback version for security, functionality, etc. The vulnerable version list and the allowed version list can be updated by the updated fallback version.

[0068] Examples of updates to the vulnerable version list and the allowed version list are provided below. The SW package version 1.2 can be released as follows: SW package version 1.2: major version 1.2 + fallback version 1.2, and The fallback version 1.2 includes: FBv1.2 vulnerable version list = D{0.1, 0.3, 0.7, 1.0, 1.1}, and FBv1.2 Allow Version List = A{0.2, 0.4, 0.6, 1.2, 1.3}. Where D represents Deny (Vulnerable Versions), and A represents Allow (Allowed Versions).

[0069] Subsequently, the updated SW package version 4.0 can be released as follows: SW Package 4.0: Major Version 4.0 + Backup Version 4.0, and The Backup Version 4.0 includes: FBv4.0 Vulnerable Version List = D{0.1, 0.3, 0.7, 1.0, 1.1, 1.4, 1.8, 1.9, 2.0, 2.2, 2.7, 2.9, 3.0, 3.1, 3.9}, and FBv4.0 Allow Version List = A{0.2, 0.4, 0.6, 1.2, 1.3, 1.5, 1.6, 1.9, 2.1, 2.3, 2.6, 2.8, 3.3, 3.4, 3.5}.

[0070] Subsequently, the updated SW package version 5.3 can be released as follows: SW Package 5.3: Major Version 5.3 + Backup Version 5.3, and The Backup Version 5.3 includes: FBv5.3 Vulnerable Version List = FBv4.0 Vulnerable Version List + D{4.0, 4.2, 4.8, 5.0}, and FBv5.3 Allow Version List = FBv4.0 Allow Version List + A{4.1, 4.3, 4.6, 4.7}.

[0071] In this way, each upgrade will increase the Vulnerable Version List and raise the most recent Backup Version. For example, if the user reaches version 5.3, the system will no longer be able to downgrade to any version included in the Vulnerable Version List 5.3, and can only downgrade to versions not included in the Vulnerable Version List 5.3 (or only to versions included in the Allow Version List 5.3 (if provided)) or roll back to the Backup Version 5.3.

[0072] Figure 3A flowchart of an example process for back-off protection of non-persistent software in a system. A software installation package is received (302). The software installation package includes a main version of the software and a fallback version of the software. The fallback version of the software includes a list of vulnerable versions, which includes a series of vulnerable versions of the software (which may be determined as of the release date of the fallback version of the software). The fallback version of the software is stored in the system (304). If the main version of the software is not included in the list of vulnerable versions, the main version of the software is installed (306).

[0073] The method may further include: receiving a second software installation package for upgrade or downgrade. The second software installation package includes a second main version of the software and a second fallback version of the software. The second fallback version of the software includes a second list of vulnerable versions, which includes a series of vulnerable versions of the software determined as of the release date of the second fallback version of the software. If the second fallback version of the software is a higher version than the fallback version of the software stored in the system, the fallback version of the software stored in the system may be updated. If the second fallback version of the software is not a higher version than the fallback version of the software stored in the system, the fallback version of the software stored in the system may remain unchanged. If the second main version of the software is not included in the list of vulnerable versions stored in the system, the second main version of the software may be installed, and if the second main version of the software is included in the list of vulnerable versions stored in the system, the second main version of the software may not be installed in the system.

[0074] The main version of the software may be uninstalled. In such a case, after uninstalling the main version of the software, the fallback version may remain in the system without any change.

[0075] If the main version of the software is included in the list of vulnerable versions, the fallback version rather than the main version of the software may be installed.

[0076] In some examples, the fallback version of the software may be stored by the operating system or by a delivery mechanism in a fallback version repository. In some examples, the fallback version of the software may be stored in a secure storage device at a registry hive in hardware or protected by the operating system.

[0077] In some examples, the fallback version of the software may further include a list of allowed versions indicating the versions of the software that are allowed to be installed. The main version of the software may be installed only if the main version of the software is included in the list of allowed versions.

[0078] In some examples, a software installation package, a primary version of the software, and a fallback version of the software may each be signed by a separate digital signature, and if the software installation package, the primary version of the software, and the fallback version of the software are all verified by the corresponding digital signatures, the primary version of the software is installed and the fallback version of the software is stored in the system.

[0079] Figure 4 is a flowchart of an example process for anti-rollback protection of non-persistent software in a system. In the example method, a software installation package may be provided to the system for installation or update (402). The software installation package may include a primary version of the software and a fallback version of the software. The fallback version of the software includes a list of vulnerable versions that includes a series of vulnerable versions of the software as determined as of the release date of the fallback version of the software.

[0080] Figure 5 is a block diagram of an electronic device 600 that includes at least one of the electronic components and / or methods described herein. The electronic device 600 is merely one example of an electronic device in which the forms of the electronic components and / or methods described herein may be used. Examples of the electronic device 600 include, but are not limited to, personal computers, tablet computers, mobile phones, gaming devices, MP3 or other digital music players, and the like. In this example, the electronic device 600 includes a data processing system that includes a system bus 602 for coupling the various components of the electronic device 600. The system bus 602 provides a communication link between the various components of the electronic device 600 and may be implemented as a single bus, as a combination of buses, or in any other suitable manner.

[0081] An electronic component 610 as described herein may be coupled to the system bus 602. The electronic component 610 may include any circuit or combination of circuits. In one embodiment, the electronic component 610 includes a processor 612, which may be of any type. As used herein, "processor" means any type of computing circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a graphics processor, a digital signal processor (DSP), a multi-core processor, or any other type of processor or processing circuit.

[0082] Other types of circuits that may be included in the electronic component 610 are custom circuits, application-specific integrated circuits (ASICs), etc., such as, for example, one or more circuits (such as the communication circuit 614) for use in wireless devices such as mobile phones, tablet computers, laptop computers, two-way radios, and similar electronic systems. The IC can perform any other type of function.

[0083] The electronic device 600 may also include an external memory 620, which in turn may include one or more memory elements suitable for a particular application, such as a main memory 622 in the form of a random access memory (RAM), one or more hard drives 624, and / or one or more drives for handling removable media 626 such as compact disks (CDs), flash cards, digital video disks (DVDs), etc.

[0084] The electronic device 600 may also include a display device 616, one or more speakers 618, and a keyboard and / or controller 630, which may include a mouse, trackball, touch screen, voice recognition device, or any other device that allows a system user to input information into the electronic device 600 and receive information from the electronic device 600.

[0085] Figure 6FIG. 700 illustrates a computing device according to one implementation of the present invention. The computing device 700 houses a board 702. The board 702 may include a plurality of components, including but not limited to a processor 704 and at least one communication chip 706. The processor 704 is physically and electrically coupled to the board 702. In some implementations, at least one communication chip 706 is also physically and electrically coupled to the board 702. In further implementations, the communication chip 706 is part of the processor 704. Depending on its application, the computing device 700 may include other components that may or may not be physically and electrically coupled to the board 702. These other components include but are not limited to volatile memory (e.g., DRAM), non-volatile memory (e.g., ROM), flash memory, graphics processors, digital signal processors, cryptographic processors, chip sets, antennas, displays, touch screen displays, touch screen controllers, batteries, audio codecs, video codecs, power amplifiers, global positioning system (GPS) devices, compasses, accelerometers, gyroscopes, speakers, cameras, and mass storage devices (such as hard disk drives, compact disks (CDs), digital versatile disks (DVDs), etc.). The communication chip 706 implements wireless communication for transmitting data to and from the computing device 700. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communication channels, etc. that enable data to be transmitted through a non-solid medium by using modulated electromagnetic radiation. The term does not imply that the associated device does not contain any wires, but in some embodiments, the associated device may not contain any wires. The communication chip 706 may implement any of a variety of wireless standards or protocols, including but not limited to Wi-Fi (IEEE 802.11 series), WiMAX (IEEE 802.16 series), IEEE 802.20, long term evolution (LTE), Ev-DO, HSPA+, HSDPA+, HSUPA+, EDGE, GSM, GPRS, CDMA, TDMA, DECT, Bluetooth and its derivatives, and any other wireless protocols referred to as 3G, 4G, 5G, and higher generations. The computing device 700 may include multiple communication chips 706. For example, a first communication chip 706 may be dedicated to shorter-range wireless communication, such as Wi-Fi and Bluetooth; and a second communication chip 706 may be dedicated to longer-range wireless communication, such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, etc. The processor 704 of the computing device 700 includes an integrated circuit die encapsulated within the processor 704.In some implementations of the present invention, the integrated circuit die of the processor includes one or more devices assembled in a package based on ePLB or eWLB P0P, which, according to an implementation of the present invention, includes a molding layer that directly contacts the substrate. The term "processor" may refer to any device or portion of a device that processes electronic data from registers and / or memories to transform the electronic data into other electronic data that can be stored in registers and / or memories. The communication chip 706 also includes an integrated circuit die encapsulated within the communication chip 706. According to another implementation of the present invention, the integrated circuit die of the communication chip includes one or more devices assembled in a package based on ePLB or eWLB P0P, which, according to an implementation of the present invention, includes a molding layer that directly contacts the substrate.

[0086] Figure 7 Are included to show examples of higher-level device applications for the disclosed embodiments. Embodiments of the MAA cantilevered heat pipe device can be found in several parts of a computing system. In an embodiment, the MAA cantilevered heat pipe is part of a communication device such as one fixed to a cellular communication tower. The MAA cantilevered heat pipe may also be referred to as the MAA device. In an embodiment, the computing system 2800 includes, but is not limited to, a desktop computer. In an embodiment, the system 2800 includes, but is not limited to, a laptop computer. In an embodiment, the system 2800 includes, but is not limited to, a netbook. In an embodiment, the system 2800 includes, but is not limited to, a tablet. In an embodiment, the system 2800 includes, but is not limited to, a notebook computer. In an embodiment, the system 2800 includes, but is not limited to, a personal digital assistant (PDA). In an embodiment, the system 2800 includes, but is not limited to, a server. In an embodiment, the system 2800 includes, but is not limited to, a workstation. In an embodiment, the system 2800 includes, but is not limited to, a cellular phone. In an embodiment, the system 2800 includes, but is not limited to, a mobile computing device. In an embodiment, the system 2800 includes, but is not limited to, a smart phone. In an embodiment, the system 2800 includes, but is not limited to, an Internet device. Other types of computing devices may be configured with microelectronic devices including embodiments of the MAA device.

[0087] In an embodiment, the processor 2810 has one or more processing cores 2812 and 2812N, where 2812N represents the Nth processor core inside the processor 2810, and N is a positive integer. In an embodiment, the electronic device system 2800 uses an MAA device embodiment, and the MAA device embodiment includes a plurality of processors, and the plurality of processors includes 2810 and 2805, where the processor 2805 has logic similar to or the same as that of the processor 2810. In an embodiment, the processing core 2812 includes, but is not limited to: prefetch logic for fetching instructions, decoding logic for decoding instructions, execution logic for executing instructions, and so on. In an embodiment, the processor 2810 has a cache memory 2816 for caching at least one of instructions and data for the MAA device in the system 2800. The cache memory 2816 can be organized into a hierarchical architecture including one or more levels of cache memory.

[0088] In an embodiment, the processor 2810 includes a memory controller 2814, and the memory controller 2814 is operable to perform functions enabling the processor 2810 to access the memory 2830 and communicate with the memory 2832, where the memory 2830 includes at least one of a volatile memory 2832 and a non-volatile memory 2834. In an embodiment, the processor 2810 is coupled to the memory 2830 and the chipset 2820. The processor 2810 can also be coupled to a wireless antenna 2878 to communicate with any device configured to transmit and / or receive wireless signals. In an embodiment, the wireless antenna interface 2878 operates in accordance with, but is not limited to, the IEEE 802.11 standard and its related series, Home Plug AV (HPAV), Ultra Wide Band (UWB), Bluetooth, WiMax, or any form of wireless communication protocol.

[0089] In an embodiment, the volatile memory 2832 includes, but is not limited to, Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 2834 includes, but is not limited to, flash memory, phase change memory (PCM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), or any other type of non-volatile memory device.

[0090] The memory 2830 stores information and instructions to be executed by the processor 2810. In an embodiment, the memory 2830 may also store temporary variables or other intermediate information while the processor 2810 executes instructions. In the illustrated embodiment, the chipset 2820 is connected to the processor 2810 via point-to-point (PtP or P-P) interfaces 2817 and 2822. Any of these PtP embodiments may be implemented using the MAA device embodiments as set forth in the present disclosure. The chipset 2820 enables the processor 2810 to connect to other elements in the MAA device embodiments in the system 2800. In an embodiment, the interfaces 2817 and 2822 operate according to PtP communication protocols such as QuickPath Interconnect (QPI), and the like. In other embodiments, different interconnections may be used.

[0091] In an embodiment, the chipset 2820 is operable to communicate with the processor 2810, 2,805N, the display device 2840, and other devices 2872, 2876, 2874, 2860, 2862, 2864, 2866, 2877, etc. The chipset 2820 is also coupled to the wireless antenna 2878 to communicate with any device configured to transmit and / or receive wireless signals.

[0092] The chipset 2820 is connected to the display device 2840 via the interface 2826. The display 2840 can be, for example, a liquid crystal display (LCD), a plasma display, a cathode ray tube (CRT) display, or any other form of visual display device. In an embodiment, the processor 2810 and the chipset 2820 are integrated into the MAA device in the system. Additionally, the chipset 2820 is connected to one or more buses 2850 and 2855 that interconnect various elements 2874, 2860, 2862, 2864, and 2866. The buses 2850 and 2855 can be interconnected together via a bus bridge 2872 (such as at least one MAA device embodiment). In an embodiment, the chipset 2820 is coupled to the non-volatile memory 2860, the mass storage device(s) 2862, the keyboard / mouse 2864, and the network interface 2866 through the interfaces 2824 and 2874, at least one of the smart TV 2876 and the consumer electronic device 2877, etc.

[0093] In an embodiment, the mass storage device 2862 includes, but is not limited to, a solid state drive, a hard disk drive, a universal serial bus flash memory drive, or any other form of computer data storage medium. In one embodiment, the network interface 2866 is implemented by any type of well-known network interface standard, including but not limited to an Ethernet interface, a universal serial bus (USB) interface, a Peripheral Component Interconnect (PCI) Express (PCIe) interface, a wireless interface, and / or any other suitable type of interface. In one embodiment, the wireless interface operates in accordance with, but is not limited to, the IEEE 802.11 standard and its related series, HomePlug AV (HPAV), ultra-wideband (UWB), Bluetooth, WiMax, or any form of wireless communication protocol.

[0094] Although Figure 7 the modules shown in

[0095] are described as separate blocks within the MAA device embodiment in the computing system 2800, the functions performed by some of these blocks can be integrated within a single semiconductor circuit or can be implemented using two or more separate integrated circuits. For example, although the cache memory 2816 is depicted as a separate block within the processor 2810, the cache memory 2816 (or selected aspects of 2816) can be incorporated into the processor core 2812.

[0096] Another example is a computer program having program code for performing at least one of the methods described herein when the computer program is executed on a computer, a processor, or a programmable hardware component. Another example is a machine-readable storage device including machine-readable instructions that, when executed, implement a method or apparatus as described herein. A further example is a machine-readable medium including code that, when executed, causes a machine to perform any of the methods described herein.

[0097] The examples described herein can be summarized as follows:

[0098] An example (e.g., Example 1) relates to a method for fallback protection of non-persistent software in a system. The method includes: receiving a software installation package, where the software installation package includes a primary version of the software and a fallback version of the software, and the fallback version of the software includes a list of vulnerable versions that includes a series of vulnerable versions of the software; storing the fallback version of the software in the system; and installing the primary version of the software if the primary version of the software is not included in the list of vulnerable versions.

[0099] Another example (e.g., Example 2) relates to the previously described example (e.g., Example 1), where the method further includes: receiving a second software installation package, where the second software installation package includes a second primary version of the software and a second fallback version of the software, and the second fallback version of the software includes a second list of vulnerable versions that includes a series of vulnerable versions of the software; and updating the fallback version of the software stored in the system if the second fallback version of the software is a higher version than the fallback version of the software stored in the system. If the second fallback version of the software is not a higher version than the fallback version of the software stored in the system, the fallback version of the software stored in the system may remain unchanged.

[0100] Another example (e.g., Example 3) relates to the previously described example (e.g., Example 2), where the method further includes: installing the second primary version of the software if the second primary version of the software is not included in the list of vulnerable versions stored in the system. If the second primary version of the software is included in the list of vulnerable versions stored in the system, the second primary version of the software is not installed in the system.

[0101] Another example (e.g., Example 4) relates to the previously described example (e.g., any one of Examples 1-3), where the method further includes: uninstalling the primary version of the software. After uninstalling the primary version of the software, the fallback version remains in the system without any change.

[0102] Another example (e.g., Example 5) relates to the previously described examples (e.g., any one of Examples 1-4), wherein the method further comprises: installing a fallback version of the software if the major version of the software is included in the list of vulnerable versions.

[0103] Another example (e.g., Example 6) relates to the previously described examples (e.g., any one of Examples 1-5), wherein the fallback version of the software is stored by the operating system in a fallback version repository.

[0104] Another example (e.g., Example 7) relates to the previously described examples (e.g., any one of Examples 1-5), wherein the fallback version of the software is stored in a secure storage device at a registry hive in hardware or protected by the operating system.

[0105] Another example (e.g., Example 8) relates to the previously described examples (e.g., any one of Examples 1-7), wherein the fallback version of the software further comprises an allowed version list that includes versions of the software that are allowed to be installed, wherein if the major version of the software is included in the allowed version list, the major version of the software is installed.

[0106] Another example (e.g., Example 9) relates to the previously described examples (e.g., any one of Examples 1-8), wherein the software installation package, the major version of the software, and the fallback version of the software are each signed by a separate digital signature, wherein if the software installation package, the major version of the software, and the fallback version of the software are all verified by their respective digital signatures, the major version of the software is installed and the fallback version of the software is stored in the system.

[0107] An example (e.g., Example 10) relates to an apparatus for anti-rollback protection for non-persistent software. The apparatus includes processing circuitry and a storage device. The processing circuitry is configured to receive a software installation package. The software installation package includes a major version of the software and a fallback version of the software, and the fallback version of the software includes a list of vulnerable versions that includes a series of vulnerable versions of the software. The storage device is configured to store the fallback version of the software. The processing circuitry is configured to: install the major version of the software if the major version of the software is not included in the list of vulnerable versions.

[0108] Another example (e.g., Example 11) relates to the previously described example (e.g., Example 10), where the processing circuitry is configured to receive a second software installation package, where the second software installation package includes a second major version of the software and a second fallback version of the software, and the second fallback version of the software includes a second list of vulnerable versions, the second list of vulnerable versions including a series of vulnerable versions of the software. The processing circuitry is configured to: update the fallback version of the software stored in the storage device if the second fallback version of the software is a higher version than the fallback version of the software stored in the storage device; and make no change to the fallback version of the software stored in the storage device if the second fallback version of the software is not a higher version than the fallback version of the software stored in the storage device.

[0109] Another example (e.g., Example 12) relates to the previously described example (e.g., Example 11), where the processing circuitry is configured to: install the second major version of the software if the second major version of the software is not included in the list of vulnerable versions stored in the storage device; and not install the second major version of the software if the second major version of the software is included in the list of vulnerable versions stored in the storage device.

[0110] Another example (e.g., Example 13) relates to the previously described example (e.g., any one of Examples 10 - 12), where the processing circuitry is configured to uninstall the major version of the software. After uninstalling the major version of the software, the fallback version remains in the storage device without any change.

[0111] Another example (e.g., Example 14) relates to the previously described example (e.g., any one of Examples 10 - 13), where the processing circuitry is configured to: install the fallback version of the software if the major version of the software is listed in the list of vulnerable versions.

[0112] Another example (e.g., Example 15) relates to the previously described example (e.g., any one of Examples 10 - 14), where the fallback version of the software is stored by the operating system in a fallback version repository.

[0113] Another example (e.g., Example 16) relates to the previously described example (e.g., any one of Examples 10 - 15), where the fallback version of the software is stored in a secure storage device in a registry hive in hardware or protected by the operating system.

[0114] Another example (e.g., Example 17) relates to a previously described example (e.g., any one of Examples 10-16), wherein the fallback version of the software further includes a permitted version list that indicates the versions of the software that are permitted to be installed, and wherein the processing circuitry is configured to: install the primary version of the software if the primary version of the software is included in the permitted version list.

[0115] Another example (e.g., Example 18) relates to a previously described example (e.g., any one of Examples 10-17), wherein the software installation package, the primary version of the software, and the fallback version of the software are each signed by a separate digital signature, and wherein the processing circuitry is configured to: install the primary version of the software and store the fallback version of the software in a storage device if the software installation package, the primary version of the software, and the fallback version of the software are all verified by their respective digital signatures.

[0116] Another example (e.g., Example 19) relates to a method for anti-rollback protection of non-persistent software in a system. The method includes: providing a software installation package. The software installation package includes a primary version of the software and a fallback version of the software, and the fallback version of the software includes a list of vulnerable versions that includes a series of vulnerable versions of the software.

[0117] Another example (e.g., Example 20) relates to a non-transitory machine-readable medium that includes code that, when executed, causes a machine to perform the method described in any one of Examples 1-9 and 19.

[0118] Another example (e.g., Example 21) relates to a computer program that has program code for performing the method described in any one of Examples 1-9 and 19 when the computer program is executed on a computer, a processor, or a programmable hardware component.

[0119] Aspects and features that are mentioned and described in conjunction with one or more of the previously detailed examples and figures may also be combined with one or more of the other examples in order to replace the same features of the other examples or to additionally introduce features into the other examples.

[0120] The example may also be a computer program, or may also involve a computer program having program code for performing one or more of the methods described above when the computer program is executed on a computer or a processor. The steps, operations, or processes of the various methods described above may be performed by a programmed computer or processor. The example may also cover a program storage device, such as a digital data storage medium, which is machine-readable, processor-readable, or computer-readable and encodes a program of machine-executable, processor-executable, or computer-executable instructions. The instructions perform some or all of the actions of the methods described above, or cause the performance of some or all of the actions of the methods described above. For example, the program storage device may include or may be a digital memory, a magnetic storage medium (such as disks and tapes), a hard drive, or an optically readable digital data storage medium. Further examples may also cover a computer, a processor, or a control unit programmed to perform the actions of the methods described above, or a (field) programmable logic array ((field)programmable logic arrays, (F)PLA) or a (field) programmable gate array ((field)programmable gate array, (F)PGA) programmed to perform the actions of the methods described above.

[0121] The description and drawings merely illustrate the principles of the present disclosure. In addition, all examples recited herein are expressly primarily intended for teaching purposes only to assist the reader in understanding the principles of the present disclosure and the concepts contributed by the inventors to further the art. All statements of the principles, aspects, and examples of the present disclosure and their specific examples are intended to cover their equivalents.

[0122] A functional block represented as a “means for...” performing a certain function may refer to a circuit configured to perform a certain function. Thus, a “means for something” may be implemented as a “means configured to or adapted for something,” such as a device or a circuit configured to or adapted for the corresponding task.

[0123] The functions of the various elements shown in the drawings (including any functional blocks labeled as "means", "means for providing a sensor signal", "means for generating a transmission signal", etc.) can be implemented in the form of dedicated hardware, such as "signal provider", "signal processing unit", "processor", "controller", etc., and hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by multiple individual processors, some or all of which can be shared. However, the terms "processor" or "controller" so far are not limited to hardware specifically capable of executing software, but can include digital signal processor (DSP) hardware, network processors, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage devices. It can also include other conventional and / or customized hardware.

[0124] A block diagram can, for example, illustrate a high-level circuit diagram implementing the principles of the present disclosure. Similarly, a flowchart, a flow chart diagram, a state transition diagram, pseudocode, etc. can represent various processes, operations, or steps, which can, for example, be substantially represented in a computer-readable medium and thereby be executed by a computer or a processor, whether or not these computers or processors are explicitly shown. The methods disclosed in the specification or in the claims can be implemented by an apparatus having means for performing each of the corresponding actions of these methods.

[0125] It should be understood that the disclosure of a plurality of actions, processes, operations, steps, or functions in the specification or in the claims may not be construed as being within a particular order, unless explicitly or implicitly stated otherwise, for example, for technical reasons. Thus, the disclosure of a plurality of actions or functions will not limit them to a particular order, unless such actions or functions are non-interchangeable for technical reasons. In addition, in some examples, a single action, function, process, operation, or step may respectively include and / or may be respectively decomposed into multiple sub-steps, sub-functions, sub-processes, sub-operations, or sub-steps. Unless explicitly excluded, such sub-actions can be included in the disclosure of the single action and as part of the disclosure of the single operation.

[0126] In addition, the appended claims are hereby incorporated into the detailed description, where each claim can stand on its own as a separate example. Although each claim can stand on its own as a separate example, it should be noted that while in the claims a dependent claim can refer to a particular combination of one or more other claims, other examples can also include a combination of that dependent claim with the subject matter of each other dependent claim or independent claim. Such combinations are expressly contemplated herein unless it is stated that a particular combination is not desired. In addition, it is also intended that the features of a claim be included in any other independent claim, even if that claim is not directly dependent on that independent claim.

[0127] As used herein, the term "module" refers to logic for performing one or more operations in accordance with the present disclosure that can be implemented using hardware components or devices, software or firmware running on a processing unit, or a combination thereof. The software and firmware can be embodied as instructions and / or data stored on a non-transitory computer-readable storage medium. As used herein, the term "circuitry" can include, alone or in any combination, non-programmable (hardwired) circuitry, programmable circuitry such as a processing unit, state machine circuitry, and / or firmware storing instructions executable by the programmable circuitry. The modules described herein can be collectively or individually embodied as circuitry forming part of a computing system. Thus, any one of the modules can be implemented as circuitry. A computing system that is said to be programmed to perform a method can be programmed to perform the method via software, hardware, firmware, or a combination thereof.

[0128] Any of the disclosed methods (or portions thereof) can be implemented as computer-executable instructions or a computer program product. Such instructions can cause a computing system or one or more processing units capable of executing the computer-executable instructions to perform any of the disclosed methods. As used herein, the term "computer" refers to any computing system or device described or referred to herein. Thus, the term "computer-executable instructions" refers to instructions that can be executed by any computing system or device described or referred to herein.

[0129] Computer-executable instructions or computer program products, as well as any data created and / or used during the implementation of the disclosed technology, may be stored on one or more tangible or non-transitory computer-readable storage media, such as volatile memory (e.g., DRAM, SRAM), non-volatile memory (e.g., flash memory, chalcogenide-based phase change non-volatile memory), optical media discs (e.g., DVD, CD), and magnetic storage (e.g., tape storage, hard disk drive). The computer-readable storage media may be included in computer-readable storage devices such as solid-state drives, USB flash drives, and memory modules. Alternatively, any of the methods (or portions thereof) disclosed herein may be performed by hardware components including non-programmable circuitry. In some examples, any of the methods herein may be performed by a combination of non-programmable hardware components and one or more processing units that execute computer-executable instructions stored on a computer-readable storage medium.

[0130] Computer-executable instructions may be part of, for example, an operating system of a computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein may be performed by computer-executable instructions executed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to computer-executable instructions may be downloaded to the computing system from a remote server.

[0131] Further, it should be understood that the implementation of the disclosed technology is not limited to any particular computer language or program. For example, the disclosed technology may be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Similarly, the disclosed technology is not limited to any particular computer system or any particular type of hardware.

[0132] In addition, any example in a software-based example (including, for example, computer-executable instructions for causing a computer to perform any of the methods disclosed herein) may be uploaded, downloaded, or remotely accessed by suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, a cable (including a fiber optic cable), magnetic communication, electromagnetic communication (including RF, microwave, ultrasonic, and infrared communication), electronic communication, or other such communication means.

[0133] As used in this application and the claims, a list of items joined by the term "and / or" can mean any combination of the listed items. For example, the phrase "A, B, and / or C" can mean A; B; C; A and B; A and C; B and C; or A, B, and C. As used in this application and the claims, a list of items joined by the term "at least one of..." can mean any combination of the listed items. For example, the phrase "at least one of A, B, or C" can mean A; B; C; A and B; A and C; B and C; or A, B, and C. Moreover, as used in this application and the claims, a list of items joined by the term "one or more of..." can mean any combination of the listed items. For example, the phrase "one or more of A, B, and C" can mean A; B; C; A and B; A and C; B and C; or A, B, and C.

[0134] The disclosed methods, apparatuses, and systems should not be construed in any way as limiting. Instead, the present disclosure is directed, both individually and in various combinations and sub - combinations with each other, to all novel and non - obvious features and aspects of the various disclosed examples. The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor do the disclosed examples require the presence of any one or more particular advantages or the solution of any one or more particular problems.

[0135] The description of the operating theory, scientific principles, or other theories presented herein with reference to the disclosed apparatus or method is provided for better understanding and is not intended to limit the scope. The apparatus and method in the appended claims are not limited to those that operate in the manner described by such operating theories.

[0136] Although, for convenience of presentation, the operations of some of the disclosed methods are described in a particular, sequential order, it should be understood that this description covers rearrangements, unless the specific language set forth herein requires a particular ordering. For example, in some cases, operations described sequentially can be rearranged or performed simultaneously. Moreover, for simplicity, the figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

Claims

1. A method for anti-rollback protection of non-persistent software in a system, comprising: Receive a software installation package, wherein the software installation package includes a main version of software and a backup version of the software, and the backup version of the software includes a vulnerable version list, and the vulnerable version list includes a series of vulnerable versions of the software; storing the backup version of the software in the system; and If the major version of the software is not listed in the vulnerable version list, the major version of the software is installed.

2. The method of claim 1, further comprising: receiving a second software installation package, wherein the second software installation package includes a second main version of the software and a second backup version of the software, and the second backup version of the software includes a second vulnerable version list, and the second vulnerable version list includes a series of vulnerable versions of the software; and if the second backup version of the software is a higher version than the backup version of the software stored in the system, updating the backup version of the software stored in the system, If the second backup version of the software is not a higher version than the backup version of the software stored in the system, the backup version of the software stored in the system is not changed.

3. The method of claim 2, further comprising: If the second major version of the software is not included in the list of vulnerable versions stored in the system, installing the second major version of the software, Wherein, if the second major version of the software is included in the vulnerable version list stored in the system, the second major version of the software is not installed in the system.

4. The method according to any one of claims 1 to 3, further comprising: The main version of the software is uninstalled, wherein the backup version remains in the system without any changes after the main version of the software is uninstalled.

5. The method according to any one of claims 1 to 4, further comprising: If the main version of the software is listed in the vulnerable version list, the backup version of the software is installed.

6. The method according to any one of claims 1 to 5, wherein: The backup version of the software is stored by the operating system in a backup version repository.

7. The method according to any one of claims 1 to 6, wherein: The backup version of the software is stored in secure storage in hardware or at a registry nest protected by the operating system.

8. The method according to any one of claims 1 to 7, wherein: The backup version of the software further includes an allowed version list including versions of the software that are allowed to be installed, wherein if the main version of the software is included in the allowed version list, the main version of the software is installed.

9. The method according to any one of claims 1 to 8, wherein: The software installation package, the main version of the software and the backup version of the software are each signed by a separate digital signature, wherein if the software installation package, the main version of the software and the backup version of the software are all verified by the corresponding digital signatures, the main version of the software is installed and the backup version of the software is stored in the system.

10. An apparatus for anti-rollback protection of non-persistent software, comprising: a processing circuit system configured to receive a software installation package, wherein the software installation package includes a main version of software and a backup version of the software, and the backup version of the software includes a vulnerable version list, the vulnerable version list including a series of vulnerable versions of the software; and a storage device configured to store the backup version of the software, The processing circuit system is configured to: if the main version of the software is not included in the vulnerable version list, install the main version of the software.

11. The device of claim 10, wherein: The processing circuit system is configured to receive a second software installation package, wherein the second software installation package includes a second main version of the software and a second backup version of the software, and the second backup version of the software includes a second vulnerable version list, the second vulnerable version list includes a series of vulnerable versions of the software, and Wherein, the processing circuit system is configured to: update the backup version of the software stored in the storage device if the second backup version of the software is a higher version than the backup version of the software stored in the storage device; and make no changes to the backup version of the software stored in the storage device if the second backup version of the software is not a higher version than the backup version of the software stored in the storage device.

12. The device of claim 11, wherein: The processing circuit system is configured to: install the second main version of the software if the second main version of the software is not included in the vulnerable version list stored in the storage device; and not install the second main version of the software if the second main version of the software is included in the vulnerable version list stored in the storage device.

13. The device according to any one of claims 10 to 12, wherein: The processing circuitry is configured to uninstall the main version of the software, wherein the backup version remains in the storage device without any changes after uninstalling the main version of the software.

14. The device according to any one of claims 10 to 13, wherein: The processing circuitry is configured to install the backup version of the software if the primary version of the software is listed in the vulnerable version list.

15. The device according to any one of claims 10 to 14, wherein: The backup version of the software is stored by the operating system in a backup version repository.

16. The device according to any one of claims 10 to 15, wherein: The backup version of the software is stored in secure storage in hardware or at a registry nest protected by the operating system.

17. The device according to any one of claims 10 to 16, wherein: The backup version of the software further includes an allowed version list, which indicates versions of the software that are allowed to be installed, wherein the processing circuit system is configured to: if the main version of the software is included in the allowed version list, then install the main version of the software.

18. The device according to any one of claims 10 to 17, wherein: The software installation package, the main version of the software and the backup version of the software are each signed by a separate digital signature, wherein the processing circuit system is configured to: if the software installation package, the main version of the software and the backup version of the software are all verified by the corresponding digital signatures, then the main version of the software is installed and the backup version of the software is stored in the storage device.

19. A method for anti-rollback protection of non-persistent software in a system, comprising: A software installation package is provided, wherein the software installation package includes a main version of software and a backup version of the software, and the backup version of the software includes a vulnerable version list, and the vulnerable version list includes a series of vulnerable versions of the software.

20. A non-transitory machine-readable medium comprising code which, when executed, causes a machine to perform the method of any one of claims 1-9 and claim 19.

Images