1. Technical Field
This disclosure relates to storage devices, which can include disk drives and solid state memory subsystems, for example. More particularly, this disclosure relates to techniques for managing data security in a memory subsystem.
2. Description of the Related Art
Storage subsystems such as disk drives, solid state memories, and the like, generally conform to certain security criteria. Such security measures are intended to protect user data from unauthorized access, which can come from rogue firmware installed on the subsystem, as one example. Existing techniques involve the use encryption, but can increase gate count by undesirable amounts in some cases. Thus, there is a need for a storage subsystem capable of managing drive security in an efficient and robust manner.
Embodiments described herein include systems and methods for managing security in a storage subsystem. Certain of these embodiments involve the use of a buffer protection module configured to intelligently police requests for access to the subsystem buffer memory. Specific embodiments of systems and processes will now be described with reference to the drawings. This description is intended to illustrate specific embodiments of the inventions, and is not intended to be limiting. Thus, nothing in this description is intended to imply that any particular component, step or characteristic is essential. The inventions are defined only by the claims.
The host block 103 generally provides an interface between the host and the other components of the subsystem 100. The encryption module 104 can implement any appropriate encryption scheme or set of encryption schemes. Commands from the host 102 can include requests to access user and non-user data, and the user data may be subject to particular security requirements. User data may generally include any data written to the subsystem by the host 202 during normal drive operation. Some examples of non-user data are subsystem configuration data and subsystem firmware code. Thus, on write requests the encryption module 104 generally encrypts the user data before the data is written to the buffer 106. The storage subsystem processors 108 therefore have access only to encrypted user data, providing protection from possible unauthorized access by firmware executing in one of the subsystem processors 108, or from other unauthorized sources. Including the encryption module 104 before the buffer in the subsystem data path can significantly raise the overall gate count of the subsystem 100 in some cases. Where the encryption module 104 is arranged in the manner depicted in
System Overview
Positioning the encryption module 204 after the buffer 206 can advantageously reduce the subsystem gate count, reducing implementation cost and power consumption. Where the encryption module 204 is arranged in the manner depicted in
The non-volatile memory 210 can include at least one non-volatile memory device, which may be a hard-disk, a solid-state memory, some other type of addressable storage subsystem, or any combination thereof. The non-volatile memory 210 is arranged as a plurality of addressable memory locations that can be organized in a variety of manners.
The buffer 206 can include or reside in a portion of an addressable memory, which in one embodiment is a volatile memory. The volatile memory can be dynamic random access memory (DRAM), such as dual data rate (DDR) DRAM, for example. In other cases, the buffer 206 includes or resides in non-volatile memory. The buffer 206 in some embodiments comprises or is implemented in a memory that is separate from and/or different the non-volatile memory 210.
The storage subsystem processors 208 can include a variety or processors configured to perform corresponding drive functions to manage the operation of the storage subsystem 200. As just a few examples, the subsystem processors 208 can include one or more of a main processor, an interface processor, a flash processor, or a servo processor. The processors 208 may include microprocessors executing firmware code, field-programmable gate arrays (FPGAs), application-specific circuitry, or combinations thereof. Firmware may be stored in any appropriate type of non-transitory computer readable medium, such as a solid state memory device. Because the host 202 and the subsystem processors 208 have access to the buffer 206, they may also be referred to herein as “buffer clients”.
The encryption module 204 can implement any appropriate encryption scheme or set of encryption schemes. Similar to the subsystem processors 208, the encryption module 204 may be implemented by one or more microprocessors executing firmware, in an FPGA, in application-specific circuitry, or a combination thereof. The encryption module 204 generally encrypts data prior to writing the data to the non-volatile storage 210.
In one embodiment, the control unit 212 (including the buffer protection module 214) is implemented by a combination of application-specific circuitry and one or more microprocessors executing firmware. The control unit 212 may logically comprise a plurality of functional blocks which are each dedicated to a respective function. For instance, a host block 213 may generally act as an interface between the host 202 and the buffer 206. As another example, a disk block (not shown) may interface with the non-volatile memory 210. Other functional blocks may exist instead of or in addition to the host block 213 and the disk block.
The buffer protection module 214 in one embodiment is implemented in distributed fashion across multiple components. For example, the buffer protection module 214 may be distributed across one or more blocks of the control unit 212 (e.g., the host block 213 and/or disk block). In another configuration, the buffer protection module 214 is implemented as a separate module. The buffer protection module 214 can be implemented at least in part in hardware, and in one embodiment is implemented completely or substantially completely in hardware, improving performance. In another embodiment, the buffer protection module is implemented at least in part in firmware.
The buffer protection module 214 generally manages accesses to the buffer 206. In particular, the buffer protection module 214 in certain embodiments allows only authorized access to unencrypted (e.g., clear text) user data stored in the buffer 206. The access may be provided according to a security policy, which may at least in part be defined by values stored in the configuration registers 216. While the configuration registers 216 can in some embodiments provide the ability to program the buffer protection module 214 and thereby modify the security policy, the security policy or certain aspects thereof is fixed in some cases.
The secure processor 215 can modify the configuration registers 216, which may be implemented by one or more microprocessors, application-specific circuitry, or in some other appropriate fashion. Importantly, the storage subsystem processors 208 may not have the ability to modify the configuration registers 216. For example, firmware running on the secure processor 215 can write and/or read the configuration registers 216, but firmware running on the subsystem processors 208 (or other buffer clients) cannot modify the configuration registers 216. In some implementations, the secure processor 216 is the only component provided access to the configuration registers 216 and/or or capable of programming the buffer protection module 214, providing additional security. In some other cases, the buffer clients are provided some form of limited access to the configuration registers 216, such as read-only access. In this manner, the buffer clients can review the security policy by reading the configuration registers 216, but do not have the ability to modify the policy. In one embodiment, the subsystem 200 includes a separate, dedicated control channel (e.g., a separate hardware path) for communication between the secure processor 215 and the configuration registers 216.
According to the security policy, the buffer protection module 214 assigns security criteria to different portions of the buffer 206. And, each portion may be designated to a particular data type, such that data of a particular type is stored in the respective buffer portion 206. For instance, according to the security policy, the buffer protection module 214 may designate a certain set of addresses in the buffer 206 as a user data portion and assign that portion particular security criteria. As one example security criteria, the policy may allow user data segments to be directly accessible by the host block 213, and only indirectly accessible by the subsystem processors 208. Another set of addresses may be designated as a non-user data portion, and be assigned different security criteria. For instance, the non-user data portions in one embodiment are directly accessible by the subsystem processors 208, but not accessible by the host block 213.
In some cases, the security policy dictates that there are multiple portions designated to a particular data type, with the portions having different security criteria. For instance, a first portion may be designated as a user data portion and be assigned a first storage criteria, and a second (third, fourth, etc.) portion may also be designated as a user data portion, but be assigned second, different storage criteria. For instance, some user data portions may be designated as secured data portions for which the buffer protection module 214 enforces a relatively strict security policy. On the other hand, other user data portions may be designated as un-secured portions, and the buffer protection module 214 may provide more relaxed access to these portions. Similarly, there may be multiple non-user data portions of the buffer 206 having different security criteria.
Based on the assigned security criteria, the buffer protection module 214 may allow direct access to the respective buffer portions by particular subsystem components. On the other hand, the buffer protection module 214 may deny access or allow some form of limited access (e.g., indirect access) by other components. For instance, in some embodiments, the host block 213 is provided direct access to user data portions of the buffer 206, but not to non-user data portions of the buffer 206. Moreover, the subsystem processors 208 in some configurations are provided only limited (e.g., indirect) access to the user data portions of the buffer 206, and are provided direct access to non-user data portions. In general, indirect access may involve a particular buffer client instructing or requesting another component to perform a desired buffer operation, where the particular buffer client does not receive direct access to or the ability to modify the data.
The above examples are provided only for the purposes of illustration. The policy can be implemented in a variety of other ways, depending on the embodiment. For instance, while user data and non-user data portions are described above, the buffer 206 may be apportioned based on other data types or any other appropriate parameter. In addition, while the subsystem processors 208 are described for simplicity as having common associated security criteria, each of the subsystem processors 208 (or any other buffer clients) can have unique associated security criteria in other embodiments.
Example Operation of the Buffer Protection Module
The operation of the buffer protection module 214 will now be described with respect to example scenarios in which one or more components of the subsystem 200 attempt to access the buffer 206. Types of buffer access requests can include, without limitation, write, read, erase and transfer requests.
In a first example scenario, a command to perform a memory operation is issued by the host 202 and involves a request to write data to the buffer 206. In this example, the security criteria assigned to user data portions of the buffer 206 by the buffer protection module 214 allows direct access by the host block 213. The control unit 212 receives and parses the command. The buffer protection unit 214 analyzes the request, and determines whether the request to write data to the buffer 206 is authorized. For example, the buffer protection unit 214 determines whether the request is to write to a portion of the buffer 206 designated as a user data portion, or rather to a portion of the buffer 206 designated as a non-user data portion. Because the request is from the host block 213 and implicates a user data portion of the buffer 206, the buffer protection module 214 determines that the request is authorized, and allows the write request to take place. A host command involving a request to read data from the buffer 206 may be handled in a similar fashion. If, on the other hand, the host command involved a request to write to a non-user data portion of the buffer 206, the buffer protection unit 214 may have denied the request, returning an error condition to the host block 213.
According to another example scenario, one of the storage subsystem processors 208 initiates a request to read user data from the buffer 206. In the example case, the security policy implemented by the buffer protection module 214 dictates that user data portions of the buffer 206 are only indirectly accessible by the particular storage subsystem processor 208 requesting access. The buffer protection module 214 parses and analyzes the request, and determines that the request is for direct access to a user data portion of the buffer 206 by a storage subsystem processor 208 that has only indirect access to user data portions. Thus, the buffer protection module 214 denies the request. In some embodiments, the buffer protection module 214 or other component of the subsystem 200 may trigger an alert or initiate remedial action in response to the unauthorized access attempt (or in response to a threshold number of attempts).
At operational block 302, the buffer protection module 214 assigns security criteria to portions of the buffer 206. For example, the security criteria may be defined at least in part by values set in the configuration registers 216, which can in some cases by modified by a user. In some embodiments, some or all of the security criteria is fixed in hardware.
At operational block 304, the buffer protection module 214 receives a request from a buffer client (e.g., the host block 213 or a subsystem processor 208) to access a portion of the buffer. For example, the request may be to read, write or erase a particular set of addresses in the buffer. The buffer protection module 214 associates a security level or policy with the request at operational block 306. For instance, the security level may depend on the component that is requesting the access. In one embodiment, the component requesting access is the host block 213, and the security level associated with the host block 213 may be direct access to user data and no access to non-user data. In another embodiment, the component requesting access is a storage subsystem processor 208, and the security level associated with the particular storage subsystem processor is direct access to user data and only indirect access to non-user data. In one embodiment, the buffer protection 214 accesses the configuration registers 216 to determine the appropriate security level or policy.
The buffer protection module 214 can associate the security level to the request based on a variety of factors. For instance, as described, the security level can be assigned based on an identity of the requesting buffer client and a data type associated with the request. The security level can additionally be assigned based on one or more buffer addresses (e.g., a starting address) associated with the request, the length of the request, the type of request (e.g., write, read, transfer, erase), or any combination thereof. As one example, the buffer protection module 214 may determine the data type and associated security level based on a logical address or set of logical addresses associated with the request.
Upon associating the proper security level to the request, at operational block 308 the buffer protection module 214 determines whether the associated security level satisfies the security criteria for the particular portion of the buffer 206. If the security level does satisfy the security criteria, the buffer protection module 214 permits the requested access at operation block 310. For instance, where the request was from the host block 213 for access to a user data portion of the buffer 206, the buffer protection module 214 determines that the security level associated with the host block 213 satisfies the security criteria.
On the other hand, if the security level does not satisfy the security criteria, the buffer protection module 214 denies the requested access at block 312. For instance, where the request is for direct access to a user data portion of the buffer 206 by a storage subsystem processor 208, the buffer protection module 214 determines that the security level associated with the storage subsystem processor 208 does not satisfy the security criteria.
The features and attributes of the specific embodiments disclosed above may be combined in different ways to form additional embodiments, all of which fall within the scope of the present disclosure. Although certain embodiments have been disclosed, other embodiments that are apparent to those of ordinary skill in the art, including embodiments which do not provide all of the features and advantages set forth herein, are also within the scope of this disclosure. Accordingly, the scope of protection is defined only by the claims.
Number | Name | Date | Kind |
---|---|---|---|
5058162 | Santon et al. | Oct 1991 | A |
5191611 | Lang | Mar 1993 | A |
5293610 | Schwarz | Mar 1994 | A |
5297283 | Kelly et al. | Mar 1994 | A |
5418927 | Chang et al. | May 1995 | A |
5442704 | Holtey | Aug 1995 | A |
5530960 | Parks et al. | Jun 1996 | A |
5623637 | Jones et al. | Apr 1997 | A |
5805800 | Kotani et al. | Sep 1998 | A |
6003117 | Buer et al. | Dec 1999 | A |
6006190 | Baena-Arnaiz et al. | Dec 1999 | A |
6061449 | Candelore et al. | May 2000 | A |
6190257 | Takeda et al. | Feb 2001 | B1 |
6321314 | Van Dyke | Nov 2001 | B1 |
6523118 | Buer | Feb 2003 | B1 |
6633963 | Ellison et al. | Oct 2003 | B1 |
6735650 | Rothberg | May 2004 | B1 |
6738904 | Linnartz et al. | May 2004 | B2 |
6823398 | Lee et al. | Nov 2004 | B1 |
6845387 | Prestas et al. | Jan 2005 | B1 |
6895506 | Abu-Husein | May 2005 | B1 |
6968459 | Morgan et al. | Nov 2005 | B1 |
7043615 | Kobayashi et al. | May 2006 | B1 |
7093139 | Silverbrook et al. | Aug 2006 | B2 |
7149854 | Weber et al. | Dec 2006 | B2 |
7215771 | Hamlin | May 2007 | B1 |
7330970 | Field | Feb 2008 | B1 |
7376898 | Yehuda et al. | May 2008 | B1 |
7469338 | Buer | Dec 2008 | B2 |
7469345 | Shimada et al. | Dec 2008 | B2 |
7474750 | Lekatsas et al. | Jan 2009 | B2 |
7607177 | Estakhri et al. | Oct 2009 | B2 |
7765373 | Merry et al. | Jul 2010 | B1 |
7912991 | Merry et al. | Mar 2011 | B1 |
7971071 | Walkoe et al. | Jun 2011 | B2 |
8108692 | Merry et al. | Jan 2012 | B1 |
8356184 | Meyer et al. | Jan 2013 | B1 |
20020107802 | Philips | Aug 2002 | A1 |
20020141583 | Barnard et al. | Oct 2002 | A1 |
20020152377 | Bauman et al. | Oct 2002 | A1 |
20020166064 | Harrison | Nov 2002 | A1 |
20030126455 | Sako et al. | Jul 2003 | A1 |
20030145183 | Muehring | Jul 2003 | A1 |
20040117309 | Inoue et al. | Jun 2004 | A1 |
20040170175 | Frank et al. | Sep 2004 | A1 |
20040236918 | Okaue et al. | Nov 2004 | A1 |
20050005149 | Hirota et al. | Jan 2005 | A1 |
20050060481 | Belonoznik | Mar 2005 | A1 |
20050071656 | Klein et al. | Mar 2005 | A1 |
20050091509 | Herberth | Apr 2005 | A1 |
20050100163 | Buer | May 2005 | A1 |
20050125692 | Cox et al. | Jun 2005 | A1 |
20050185067 | Estakhri et al. | Aug 2005 | A1 |
20050210287 | Paatero | Sep 2005 | A1 |
20050240738 | Shirogane et al. | Oct 2005 | A1 |
20060031687 | Su et al. | Feb 2006 | A1 |
20060041934 | Hetzler | Feb 2006 | A1 |
20060059369 | Fayad et al. | Mar 2006 | A1 |
20060080526 | Kasahara et al. | Apr 2006 | A1 |
20060092049 | Dellow | May 2006 | A1 |
20060174055 | Flynn | Aug 2006 | A1 |
20060174298 | Chen et al. | Aug 2006 | A1 |
20060177068 | Hatakeyama | Aug 2006 | A1 |
20060288235 | Goto | Dec 2006 | A1 |
20070038827 | Inooka et al. | Feb 2007 | A1 |
20070067647 | Klein | Mar 2007 | A1 |
20070130625 | Lee | Jun 2007 | A1 |
20070168676 | Fayad et al. | Jul 2007 | A1 |
20070172053 | Poirier | Jul 2007 | A1 |
20070180210 | Thibadeau | Aug 2007 | A1 |
20070186117 | Klein et al. | Aug 2007 | A1 |
20070192577 | Kozuch et al. | Aug 2007 | A1 |
20070192610 | Chun et al. | Aug 2007 | A1 |
20070223705 | Kasahara et al. | Sep 2007 | A1 |
20070260811 | Merry, Jr. et al. | Nov 2007 | A1 |
20080109660 | Mitra | May 2008 | A1 |
20080126616 | Kumasawa et al. | May 2008 | A1 |
20080155180 | Shibata et al. | Jun 2008 | A1 |
20080189500 | Jennings et al. | Aug 2008 | A1 |
20080189557 | Pipitone et al. | Aug 2008 | A1 |
20080320314 | Eckleder et al. | Dec 2008 | A1 |
20090210612 | Nakanishi et al. | Aug 2009 | A1 |
20100037048 | Madan | Feb 2010 | A1 |
20100205152 | Ansari et al. | Aug 2010 | A1 |
20110154061 | Chilukuri et al. | Jun 2011 | A1 |
20110161551 | Khosravi et al. | Jun 2011 | A1 |
Number | Date | Country |
---|---|---|
0 387 599 | Sep 1990 | EP |
1 164 588 | Dec 2001 | EP |
1 587 095 | Oct 2005 | EP |
2 374 718 | Oct 2002 | GB |