lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181025152856.GD4970@thunk.org>
Date:   Thu, 25 Oct 2018 11:28:56 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Rob Herring <robh@...nel.org>
Cc:     AnilKumar Chimata <anilc@...eaurora.org>, andy.gross@...aro.org,
        david.brown@...aro.org, mark.rutland@....com,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        linux-soc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] crypto: qce: ice: Add support for Inline Crypto
 Engine

On Thu, Oct 25, 2018 at 09:55:48AM -0500, Rob Herring wrote:
> > +Introduction:
> > +=============
> > +Storage encryption has been one of the most required feature from security
> > +point of view. QTI based storage encryption solution uses general purpose
> > +crypto engine. While this kind of solution provide a decent amount of
> > +performance, it falls short as storage speed is improving significantly
> > +continuously. To overcome performance degradation, newer chips are going to
> > +have Inline Crypto Engine (ICE) embedded into storage device. ICE is supposed
> > +to meet the line speed of storage devices.
> 
> Is ICE part of the storage device or part of the host as the binding 
> suggests?

My understanding is that for this particular instantiation, the Inline
Crypto Engine is located on the SOC.

However, from the perspective of generic kernel support, the inline
crypto support could be implemented on the SOC, or in the host bus
adaptor, or as a "bump in the wire", or on the storage device.  And
whatever abstract interface in the block layer should be able to
support all of these cases.

I do not believe it would be wise to assume that inline crypto will
forever be a mobile-only thing.  I could easily see use cases in the
data center; for example, if you believe that Nation State Actors
might be trying to create "implants" that attack hard drive firmware,
per some of the Snowden leaks, creating an open design ICE engine with
auditable firmware and a trusted secure key store, and which sits
between the host CPU and the storage device might be one way to
mitigate against this threat.

					- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ