Patent Description:
Debugging and otherwise improving software commonly involves collecting a copy or snapshot of the content of a memory at the time of an event, such as an unanticipated failure of a system or subsystem, commonly referred to as a "crash. " The snapshot may be referred to as a "memory dump. " A memory dump collected at the time of a crash may be referred to as a "crash dump.

Traditionally, the scope of a crash dump covered the entire system memory. As a system memory may be very large, a traditional crash dump collection may take a substantial amount of time. More recently, crash dumps have been collected from PCDs over wireless networks. Such a remote crash dump collection may raise not only performance considerations but also security considerations. For these reasons, improvements in memory dump collection may be desirable.

<CIT> discloses that there are various methods of securing programs and data on a processor. The external address enable pin of the processor is sampled upon a power-on or reset to the processor, to determine whether or not accesses to external memory are allowed. Other changes to the external address enable pin are thereafter ignored. In addition, if it is determined that an internal memory access is occurring, the contents of such an access can be masked to prevent unauthorized viewing of the memory contents via an external memory bus. In addition, a programmable security bit may be set to disable the dumping of flash memory contents, allowing only the erasing of the flash memory.

Systems, methods, computer-readable media, and other examples are disclosed for protecting memory regions based on occurrence of an event in a computing device.

An exemplary method for protecting memory regions based on occurrence of an event in a computing device may include a subsystem of the computing device storing information in a memory controller. The information may identify one or more memory regions to be erased upon occurrence of an event. The exemplary method may further include the memory controller erasing the one or more memory regions in response to an indication the memory controller receives.

An exemplary system for protecting memory regions based on occurrence of an event in a computing device may include a memory and a memory controller. The memory controller may include memory erase logic. The memory erase logic may be configured to store information identifying one or more memory regions to be erased upon occurrence of an event. The memory erase logic may further be configured to erase the one or more memory regions in response to an indication the memory controller receives.

Another exemplary system for protecting memory regions based on occurrence of an event in a computing device may include means for storing information in a memory controller that identifies one or more memory regions to be erased upon occurrence of an event. The exemplary system may further include means for erasing the one or more memory regions in response to an indication.

An exemplary computer-readable medium for protecting memory regions based on occurrence of an event in a computing device may comprise a non-transitory computer-readable medium having instructions stored thereon in computer-executable form. The instructions, when executed by a processing system, may configure the processing system to store, under control of a subsystem of the computing device, information in a memory controller that identifies one or more memory regions to be erased upon occurrence of an event. The instructions may further configure the processing system to erase, under control of the memory controller, the one or more memory regions in response to an indication received by the memory controller.

" The word "illustrative" may be used herein synonymously with "exemplary.

As shown in <FIG>, in an illustrative or exemplary embodiment a system <NUM> may include any number of portable computing devices ("PCD"s) <NUM>, such as PCDs 102A through 102N, configured to communicate with a service provider <NUM> via one or more wireless networks <NUM>. A PCD <NUM> may be, for example, a cellular telephone such as a smartphone, or it may be a satellite telephone, a laptop or palmtop computer, a tablet, a navigation device, a smartbook, a personal digital assistant ("PDA"), an Internet-of-Things ("IoT") device, an automotive computing device, etc. The PCD <NUM> may include, among other elements (not shown for purposes of clarity), one or more memories <NUM>. The service provider <NUM> may be, for example, a manufacturer of the PCD <NUM> or a subsystem or other component of the PCD <NUM>. The service provider <NUM> may participate in services that may include debugging or otherwise improving software operating on the PCD <NUM>. Accordingly, the service provider <NUM> may desire to upload or collect a memory dump from the memory <NUM> via the one or more wireless networks <NUM>, as conceptually indicated by the broken-line arrow <NUM>. Although in this exemplary embodiment (<FIG>) the memory dump is collected via the one or more wireless networks <NUM>, in other embodiments such a memory dump may be collected via any other type of connection, such as a wired connection (e.g., via a USB cable, a JTAG interface, etc.). The term "memory dump" or "memory dump collection" as used herein broadly refers to collecting memory contents and should not be construed as limited to any particular event, reason, time, amount of data collected, etc..

Some regions of the memory <NUM> may contain sensitive data. Examples of sensitive data include data used to maintain security, data that is private to a user of the PCD <NUM>, data that embodies confidential information (e.g., trade secrets or other intellectual property) of a manufacturer of the PCD <NUM> or a related entity, etc. For security and privacy reasons, it may be desirable to prevent sensitive data from being uploaded via the networks <NUM> or other connection in a memory dump collection. Alternatively, or in addition, it may be desirable to prevent sensitive data from being accessed by unauthorized software entities in the event the system is rebooted (for any reason, including but not limited to a system crash). One solution is for a trusted software entity to maintain a database of regions of the memory <NUM> that contain sensitive yet unencrypted data, and then to erase those regions prior to the memory dump collection. A disadvantage of this solution is that the erasing operation adds performance overhead. Another disadvantage is that if the database is stored in the memory <NUM>, a system crash may render reading the database unreliable. There may also be security issues if the database can become compromised. The following solution may avoid some or all of these disadvantages.

As illustrated in <FIG>, an exemplary PCD <NUM> may include a subsystem <NUM>, a memory controller <NUM> and a memory <NUM>. The subsystem <NUM> may be an exemplary one of any number of PCD subsystems, others of which are not shown in <FIG> for purposes of clarity. The subsystem <NUM> may be coupled with the memory controller <NUM> via one or more buses or other system interconnects <NUM>. The memory controller <NUM> may be coupled with the memory <NUM> via one or more other buses or system interconnects <NUM>. In addition to the manner of operation described below with regard to protecting memory regions collected in a memory dump, the subsystem <NUM>, memory controller <NUM> and memory <NUM> may operate in a manner well understood by one of ordinary skill in the art. For example, in response to memory transaction requests (e.g., write requests, read requests, etc.) from the subsystem <NUM>, the memory controller <NUM> may store (i.e., write) data in and retrieve (i.e., read) data from locations in the memory <NUM>. As understood by one of ordinary skill in the art, in a memory transaction request the subsystem <NUM> may provide one or more commands indicating whether the request is to write data or read data and may also provide one or more addresses indicating locations in the memory <NUM>. Note that the "Data," "Address" and "Commands" arrows in <FIG> indicate the direction in which data, address and commands relating to protecting memory regions collected in a memory dump are communicated, and that data may also be communicated in the opposite direction of the "Data" arrows when data is to be written to the memory <NUM>.

The memory <NUM> may be a dynamic random access memory ("DRAM)" such as, for example, a double data-rate synchronous DRAM ("DDR-SDRAM" or, for brevity, "DDR"). In addition to the configuration described below, the memory controller <NUM> may be configured to complete memory transactions in response to memory transaction requests and to perform other conventional DDR operations, such as refresh, etc., as understood by one of ordinary skill in the art.

The subsystem <NUM> may operate under the control of software in the manner of a processor or similar device. Such software may include trusted entity ("TE") software that may configure portion of the subsystem <NUM> as a TE <NUM>. An example of the subsystem <NUM> is a central processing unit ("CPU"), which may also be referred to as an application processor ("AP").

The memory controller <NUM> may include memory erase logic <NUM>. The memory erase logic <NUM> may include any number of registers <NUM> or other hardware-based storage structures configured to store information indicating addresses or locations in the memory <NUM>.

The subsystem <NUM> (or the trusted entity <NUM>) may issue requests to the memory controller <NUM> to store information in the registers <NUM> indicating or identifying addresses or regions in the memory <NUM> to be erased by the memory erase logic <NUM> upon occurrence of a predetermined event or condition, such as, for example, a predetermined command, signal, etc. These requests or indications may be in the form of commands. In response to such a "store command" or request received from the subsystem <NUM>, the memory erase logic <NUM> may be configured to store the information identifying a region of the memory <NUM>. For example, the information may identify a starting address and size of a region, and the memory erase logic <NUM> may store the starting address and size in one of the registers <NUM>. In such an example, each register <NUM> may represent one region of a fixed size to be erased upon occurrence of the predetermined event or condition. Each time the memory controller <NUM> receives a request of the above-described type to store information in the registers <NUM>, the memory erase logic <NUM> may store the information in the next available register <NUM>. That is, the registers <NUM> may be organized in a list, and the memory erase logic <NUM> may maintain a pointer to the register <NUM> at the next location in the list after the last location in which information was stored. Nevertheless, alternative schemes for selecting from among the registers <NUM> or other storage structures and storing the information therein will occur readily to one of ordinary skill in the art in view of these teachings and examples.

The subsystem <NUM> (or the trusted entity <NUM>) may also issue requests or other indications to the memory controller <NUM> to erase the one or more memory regions identified by the information that has been stored in the registers <NUM>. These erase requests or indications may be in the form of commands. For example, the memory controller <NUM>, and in particular the memory erase logic <NUM>, may be configured to respond to an erase command. In such an example, the memory erase logic <NUM> may be configured to erase those one or more memory regions in response to an erase command received by the memory controller <NUM> from the subsystem <NUM>. The memory erase logic <NUM> may be configured to erase those one or more memory regions by sending erase commands or other commands to the memory <NUM>. The term "erase" means to render the memory contents unreadable. Accordingly, the commands sent to the memory <NUM> may include commands to obscure any physical manifestations of the data that had been stored in those memory regions, an effect sometimes referred to as wiping or scribbling. For example, the commands may include commands to over-write the memory regions with one or more data patterns. The data pattern or patterns may include all "<NUM>"s, all "<NUM>"s, alternating "<NUM>"s and "<NUM>"s, random data, etc., as understood by one of ordinary skill in the art. Alternatively, or in addition, such commands could include commands that selectively power down memory cells for a duration that ensures the memory contents are lost. Still other ways of erasing the memory regions using commands will occur readily to one of ordinary skill in the art in view of these teachings and examples. After erasing the memory regions, the memory erase logic <NUM> may make all the registers <NUM> again available for storing information.

The memory erase logic <NUM> may also be coupled to reset control logic <NUM>. The reset control logic <NUM> may be configured to assert one or more reset signals in response to occurrence of certain events, such as, for example, when the PCD <NUM> is booted, or when the PCD <NUM> experiences a system crash, etc. The reset control logic <NUM> may include logic (not shown) to detect such a system crash or boot and, in response, generate a system reset signal. As the manner in which such logic may detect a system crash, system boot, etc., and the manner in which such logic may generate a system reset signal are well understood by one of ordinary skill in the art, the reset control logic <NUM> is not described in further detail herein. Nevertheless, it should be noted that one such reset signal <NUM> may be coupled to the memory erase logic <NUM>. Alternatively to, or in addition to, being configured to respond to an erase command in the manner described above, the memory erase logic <NUM> may be configured to respond to the reset signal <NUM>. In such an example, the memory erase logic <NUM> may be configured to erase the one or more memory regions identified by the information that has been stored in the registers <NUM> in response to assertion of the reset signal <NUM> by the reset control logic <NUM>. Alternatively, or in addition, the memory erase logic <NUM> may be configured to receive a signal (not shown) from the subsystem <NUM> or some other subsystem or component and may be configured to erase the one or more memory regions in response to assertion of that signal.

As illustrated in <FIG>, an exemplary method <NUM> for protecting memory regions based on occurrence of an event in a computing device may include the following. As indicated by block <NUM>, the method <NUM> may include storing information in a memory controller identifying one or more regions of a memory. As indicated by block <NUM>, the method <NUM> may include erasing the one or more memory regions in response to an indication received by the memory controller. As described above with regard to <FIG>, such an erase indication may be, for example, an erase command received from a subsystem. Alternatively or in addition, such an erase indication may be, for example, a system reset signal received from reset control logic or other signal. The above-described memory erase logic <NUM> (<FIG>) may serve as an exemplary means for performing the functions associated with blocks <NUM> and <NUM>.

As illustrated in <FIG>, another exemplary method <NUM> for protecting memory regions based on occurrence of an event in a computing device may include the following. As indicated by block <NUM>, the method <NUM> may include storing information in a memory controller identifying one or more regions of a memory. As indicated by block <NUM>, the method <NUM> may include erasing the one or more memory regions in response to an indication received by the memory controller. As indicated by block <NUM>, the method <NUM> may further include performing or controlling a memory dump collection. For example, after the memory regions have been erased in the manner described above, the contents of the memory <NUM> or one or more portions thereof may be transmitted to a remote entity. The memory contents, i.e., a memory dump, may be transmitted via, for example, a wireless network or other connection as described above with regard to <FIG>.

Referring briefly again to <FIG>, the software under which the subsystem <NUM> operates may include memory dump collection software. A portion of the subsystem <NUM>, configured by such software as a memory dump collector <NUM>, may serve as a means for collecting (including transmitting) the memory dump from the memory <NUM>. The memory dump collection software may be, for example, a portion of a high-level operating system in an example in which the subsystem <NUM> is a CPU or AP executing the high-level operating system.

As illustrated in <FIG> in operational flow diagram form, an exemplary system <NUM> may include a memory (e.g., DDR) controller <NUM> having memory erase logic <NUM>. The memory controller <NUM> and memory ease logic <NUM> may be similar to the memory controller <NUM> and memory erase logic <NUM> described above with regard to <FIG>. The system <NUM> may also include various software or firmware elements, such as a primary boot loader ("PBL") <NUM>. These software or firmware elements may be executed by a processor, such as a CPU or AP (not shown). The PBL <NUM> may be executed from a readonly memory (not shown) as part of the process of booting a computing device, such as a PCD. The PBL <NUM> may control loading (into allocated regions of DDR <NUM> or other memory) and authentication of a first trusted software entity <NUM> and a first un-trusted software entity <NUM>. Although not shown for purposes of clarity, the first trusted software entity <NUM> may be executed in a trusted or secure portion of a processor. Also note that for purposes of clarity in <FIG> the various software elements that may be loaded in the DDR <NUM> are conceptually depicted externally to the DDR <NUM>.

After loading and authenticating the first trusted software entity <NUM> and first untrusted software entity <NUM>, the PBL <NUM> may transfer execution to the first trusted software entity <NUM> to continue the boot process. The first trusted software entity <NUM> may then lock the one or more memory regions allocated to it against access by any other entities. Then, the first trusted software entity <NUM> may register those one or more memory regions in the memory erase logic <NUM>. That is, the first trusted software entity <NUM> may store information identifying the memory regions in the manner described above with regard to the trusted entity <NUM> in <FIG>.

In the illustrated embodiment, a task of the first un-trusted software entity <NUM> may be to load further software entities in the DDR <NUM>. For example, the first un-trusted software entity <NUM> may control loading and authentication of a second trusted software entity <NUM> and a second un-trusted software entity <NUM>. Like the first trusted software entity <NUM>, the second trusted software entity <NUM> may be executed in the trusted or secure portion of the processor (not shown). The second trusted software entity <NUM> may then lock the one or more memory regions allocated to it against access by any other entities. Then, the second trusted software entity <NUM> may register those one or more memory regions in the memory erase logic <NUM>. That is, the second trusted software entity <NUM> may store information identifying the memory regions in the manner described above with regard to the trusted entity <NUM> in <FIG>. Note that the first trusted software entity <NUM> and the second trusted software entity <NUM> may comprise sensitive information that would be desirable to erase before a memory dump collection or system reboot is performed. With regard to erasing memory regions before a system reboot, it may be desirable to prevent the first un-trusted software entity <NUM> or other un-trusted software entities from accessing sensitive information that may have been saved in a memory region at run time before the reboot.

The second un-trusted software entity <NUM> may be, for example, a high-level operating system or portion thereof. The second trusted software entity <NUM> may transfer execution to the second un-trusted software entity <NUM> (e.g., HLOS) to continue the boot process.

The second un-trusted software entity <NUM> (e.g., HLOS) may then allocate and load into the DDR <NUM> any number of subsystem software images <NUM>, such as a first subsystem software image 516A through an Nth subsystem software image 516N. Some or all of the subsystem software images <NUM> may comprise sensitive information that would be desirable to erase before a memory dump collection is performed. The second trusted software entity <NUM> may then lock and authenticate any memory regions containing subsystem software images <NUM> comprising sensitive information against access by any other entities. Then, the second trusted software entity <NUM> may register any such memory regions in the memory erase logic <NUM>.

After booting is complete, various subsystems of the computing device may begin operating, under control of their associated software images <NUM>. Before a memory dump collection is performed, and/or before memory regions are opened for access by untrusted software entities during a system reboot, it also may be desirable to erase any sensitive data that may be stored in memory under control of a subsystem in operation (i.e., in dynamically allocated memory regions). Accordingly, the second trusted software entity <NUM> may register any such memory regions in the memory erase logic <NUM>.

In the event of a system crash, reset control logic <NUM> may signal the memory erase logic <NUM> in the manner described above with regard to the reset control logic <NUM> (<FIG>). In response to such a system crash or system reset event, the memory erase logic <NUM> may control erasing of the one or more registered memory regions in preparation for a memory dump collection. The first trusted software entity <NUM> may unlock memory regions that it has locked, making them available for memory dump collection. The first un-trusted software entity <NUM> may then perform the memory dump collection from the memory regions that had been erased as described above as well as any other memory regions. For example, the first un-trusted software entity <NUM> may collect the data from the entire system memory (i.e., all allocated memory regions). The first un-trusted software entity <NUM> may also initiate sending the memory dump (i.e., the collected data) to a remote destination, as described above with regard to <FIG>. Alternatively, the first un-trusted software entity <NUM> may collect the memory dump and store it as a file (e.g., in flash memory, an SD card, a UFS device, etc.). The file can later be downloaded from the device or uploaded over a network.

In an alternative scenario or use case, instead of the one or more registered memory regions being erased in response to a system crash or system reset event, the one or more registered memory regions may be erased in response to a subsystem crash or subsystem reset event. For example, the second un-trusted software entity <NUM> (HLOS) may detect that one of the subsystems <NUM> has crashed. In preparation for a memory dump collection, the second un-trusted software entity <NUM> (HLOS) may then send a request to the second trusted software entity <NUM>, requesting that the one or more registered memory regions be erased. In response to such a request, the second trusted software entity <NUM> may send an erase command to the memory erase logic <NUM>. In response to the erase command, the memory erase logic <NUM> may control erasing the one or more registered memory regions. The second trusted software entity <NUM> may unlock memory regions associated with the crashed subsystem, making them available for memory dump collection. Then, the second un-trusted software entity <NUM> may perform the memory dump collection from memory regions associated with the crashed subsystem <NUM>. The second un-trusted software entity <NUM> (HLOS) may also initiate sending the memory dump (i.e., the collected data) to a remote destination.

In <FIG>, an example of a PCD <NUM> in which exemplary embodiments of systems, methods, computer-readable media, and other examples of protecting memory regions based on occurrence of an event may be provided is illustrated. For purposes of clarity, some data buses, clock signals, power supply voltages, etc., are not shown in <FIG>.

The PCD <NUM> may include an SoC <NUM>. The SoC <NUM> may include a CPU <NUM>, an NPU <NUM>, a GPU <NUM>, a DSP <NUM>, an analog signal processor <NUM>, or other processors. The CPU <NUM> may include one or more CPU cores, such as a first CPU core 604A, a second CPU core 604B, etc., through an Nth CPU core 604N.

A display controller <NUM> and a touch-screen controller <NUM> may be coupled to the CPU <NUM>. A touchscreen display <NUM> external to the SoC <NUM> may be coupled to the display controller <NUM> and the touch-screen controller <NUM>. The PCD <NUM> may further include a video decoder <NUM> coupled to the CPU <NUM>. A video amplifier <NUM> may be coupled to the video decoder <NUM> and the touchscreen display <NUM>. A video port <NUM> may be coupled to the video amplifier <NUM>. A universal serial bus ("USB") controller <NUM> may also be coupled to CPU <NUM>, and a USB port <NUM> may be coupled to the USB controller <NUM>. A subscriber identity module ("SIM") card <NUM> may also be coupled to the CPU <NUM>.

One or more memories may be coupled to the CPU <NUM>. The one or more memories may include both volatile and non-volatile memories. Examples of volatile memories include static random access memory ("SRAM") <NUM> and DRAM <NUM> and <NUM>. Such memories may be external to the SoC <NUM>, such as the DRAM <NUM>, or internal to the SoC <NUM>, such as the DRAM <NUM>. A DRAM controller <NUM> coupled to the CPU <NUM> may control the writing of data to, and reading of data from, the DRAMs <NUM> and <NUM>. The DRAM controller <NUM> may be an example of the above-described memory controllers <NUM> (<FIG>) or <NUM> (<FIG>). The DRAMs <NUM> and <NUM>, SRAM <NUM> or other memories (not shown) of the PCD <NUM> may be an example of the above-described memory <NUM> (<FIG>) or <NUM> (<FIG>).

A stereo audio CODEC <NUM> may be coupled to the analog signal processor <NUM>. Further, an audio amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>. First and second stereo speakers <NUM> and <NUM>, respectively, may be coupled to the audio amplifier <NUM>. In addition, a microphone amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>, and a microphone <NUM> may be coupled to the microphone amplifier <NUM>. A frequency modulation ("FM") radio tuner <NUM> may be coupled to the stereo audio CODEC <NUM>. An FM antenna <NUM> may be coupled to the FM radio tuner <NUM>. Further, stereo headphones <NUM> may be coupled to the stereo audio CODEC <NUM>. Other devices that may be coupled to the CPU <NUM> include one or more digital (e.g., CCD or CMOS) cameras <NUM>.

A modem or RF transceiver <NUM> may be coupled to the analog signal processor <NUM> and the CPU <NUM>. An RF switch <NUM> may be coupled to the RF transceiver <NUM> and an RF antenna <NUM>. In addition, a keypad <NUM>, a mono headset with a microphone <NUM>, and a vibrator device <NUM> may be coupled to the analog signal processor <NUM>.

The SoC <NUM> may have one or more internal or on-chip thermal sensors 670A and may be coupled to one or more external or off-chip thermal sensors 670B. An analog-to-digital converter ("ADC") controller <NUM> may convert voltage drops produced by the thermal sensors 670A and 670B to digital signals. A power supply <NUM> and a power management integrated circuit ("PMIC") <NUM> may supply power to the SoC <NUM>.

The PCD <NUM> is only one example of a device or system in which exemplary embodiments of systems, methods, computer-readable media, and other embodiments of protecting memory regions based on occurrence of an event may be provided. Other examples may include other types of computing devices or computing systems, such as those used in datacenter, automotive, IoT and other contexts.

Firmware or software may be stored in any of the above-described memories, such as DRAM <NUM> or <NUM>, SRAM <NUM>, etc., or may be stored in a local memory directly accessible by the processor hardware on which the software or firmware executes. Execution of such firmware or software may control aspects of any of the above-described methods or configure aspects any of the above-described systems. Any such memory or other non-transitory storage medium having firmware or software stored therein in computer-readable form for execution by processor hardware may be an example of a "computer-readable medium," as the term is understood in the patent lexicon.

Claim 1:
A method (<NUM>, <NUM>) for protecting memory regions based on occurrence of an event in a computing device, comprising:
storing (<NUM>, <NUM>), by a subsystem (<NUM>, <NUM>) of the computing device, information in registers (<NUM>) of a memory erase logic (<NUM>) of a memory controller (<NUM>, <NUM>) identifying one or more memory regions of a memory (<NUM>, <NUM>); and
the memory controller (<NUM>, <NUM>) receiving the indication from the subsystem (<NUM>, <NUM>), the indication comprising a command;
erasing (<NUM>, <NUM>), by the memory erase logic (<NUM>) of the memory controller (<NUM>, <NUM>), the one or more memory regions corresponding to the information identifying the one or more memory regions of the memory (<NUM>, <NUM>) in response to the indication received by the memory controller (<NUM>, <NUM>); and
performing (<NUM>) a memory dump collection from the memory (<NUM>, <NUM>) after erasing the one or more memory regions.