From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id ED1122098C8B7 for ; Wed, 18 Jul 2018 23:09:42 -0700 (PDT) From: "Li, Juston" Subject: RE: [PATCH v5 09/12] nfit/libnvdimm: add support for issue secure erase DSM to Intel nvdimm Date: Thu, 19 Jul 2018 06:09:35 +0000 Message-ID: References: <153186061802.27463.14539931103401173743.stgit@djiang5-desk3.ch.intel.com> <153186089522.27463.4537738384176593789.stgit@djiang5-desk3.ch.intel.com> In-Reply-To: Content-Language: en-US MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Elliott, Robert (Persistent Memory)" , "Jiang, Dave" , "Williams, Dan J" Cc: "dhowells@redhat.com" , "Schofield, Alison , keyrings@vger.kernel.org" , "keescook@chromium.org" , "linux-nvdimm@lists.01.org" List-ID: > -----Original Message----- > From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of > Elliott, Robert (Persistent Memory) > Sent: Wednesday, July 18, 2018 6:43 PM > To: Jiang, Dave ; Williams, Dan J > > Cc: dhowells@redhat.com; Schofield, Alison ; > keyrings@vger.kernel.org; keescook@chromium.org; linux- > nvdimm@lists.01.org > Subject: RE: [PATCH v5 09/12] nfit/libnvdimm: add support for issue secure erase > DSM to Intel nvdimm > > > Related topic: a flush is also necessary before sending the secure erase or unlock > command. Otherwise, there could be dirty write data that gets written by the > concluding flush (overwriting the now-unlocked or just-erased data). For unlock > during boot, you might assume that no writes having occurred yet, but that isn't > true for secure erase on demand. Flushing before both commands is safest. > I was wondering this too. Is it handled by the fact the DIMM must be disabled to do a secure erase? I'm assuming that means the namespace that the DIMM is a part of also must be disabled first? Then no further writes can occur and provided that dirty write data is flushed when the namespace is disabled, it should be safe to issue a secure erase. Thanks Juston _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm