On Tue, Jul 3, 2018 at 11:00 AM, James Morris wrote:
> On Mon, 2 Jul 2018, Dan Williams wrote:
>
>> If an attacker can run arbitrary code in the kernel they can get the
>> key from the ring directly, or turn on ACPI debug. A platform could
>> arrange for the DIMMs to be unlocked pre-OS to
On Mon, 2 Jul 2018, Dan Williams wrote:
> If an attacker can run arbitrary code in the kernel they can get the
> key from the ring directly, or turn on ACPI debug. A platform could
> arrange for the DIMMs to be unlocked pre-OS to minimize passphrase
> exposure,
So, either from within UEFI
On Mon, Jul 2, 2018 at 9:58 PM, Elliott, Robert (Persistent Memory)
wrote:
>
>> > Since it contains a high-value password, I recommend zeroing
>> > cmd->passphrase before calling kfree() so that data isn't seen
>> > by a subsequent kmalloc() caller (and make sure the compiler
>> > cannot optimize
> > Since it contains a high-value password, I recommend zeroing
> > cmd->passphrase before calling kfree() so that data isn't seen
> > by a subsequent kmalloc() caller (and make sure the compiler
> > cannot optimize away the clearing code).
> >
> > Also, check if the ndctl() call chain makes
On Mon, Jul 2, 2018 at 4:39 PM, Dave Jiang wrote:
> Adding support to allow query the security status of the Intel nvdimms and
> also unlock the dimm via the kernel key management APIs. The passphrase is
> expected to be pulled from userspace through keyutils. Moving the Intel
> related bits to
On Mon, Jul 2, 2018 at 6:45 PM, Elliott, Robert (Persistent Memory)
wrote:
>
>
>> -Original Message-
>> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of
>> Dave Jiang
>> Sent: Monday, July 2, 2018 6:39 PM
>> To: dan.j.willi...@intel.com
>> Cc:
> -Original Message-
> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of
> Dave Jiang
> Sent: Monday, July 2, 2018 6:39 PM
> To: dan.j.willi...@intel.com
> Cc: dhowe...@redhat.com; alison.schofi...@intel.com;
> keyri...@vger.kernel.org; keesc...@chromium.org;
