From: AnilKumar Chimata <email@example.com> To: AnilKumar Chimata <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 3/3] crypto: qce: ice: Add support for Inline Crypto Engine Date: Wed, 24 Oct 2018 17:34:53 +0530 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20181017170446.GD29710@thunk.org> Hi Theodore, Thanks for the comments, On 2018-10-17 22:34, Theodore Y. Ts'o wrote: > First, thanks for the effort for working on getting the core ICE > driver support into upstreamable patches. > > On Wed, Oct 17, 2018 at 08:47:56PM +0530, AnilKumar Chimata wrote: >> +2) Per File Encryption (PFE) >> +Per File Manager(PFM) calls QSEECom api to create the key. PFM has a >> peer comp- >> +onent(PFT) at kernel layer which gets the corresponding key index >> from PFM. >> ... >> +Further Improvements >> +==================== >> +Currently, Due to PFE use case, ICE driver is dependent upon >> dm-req-crypt to >> +provide the keys as part of request structure. This couples ICE >> driver with >> +dm-req-crypt based solution. It is under discussion to expose an >> IOCTL based >> +and registration based interface APIs from ICE driver. ICE driver >> would use >> +these two interfaces to find out if any key exists for current >> request. If >> +yes, choose the right key index received from IOCTL or registration >> based >> +APIs. If not, dont set any crypto parameter in the request. > > However, this documentation is referencing components which are not in > the mainline kernel. Sure, will clean the documentation and try to minimize the unknown components. Provided these details for better understanding of the flow. > > In the long term, what I'd like to see for per-file key support is a > clean solution which interfaces with the in-kernel fscrypt-enabled > file systems (e.g., f2fs and ext4). What I think we need to do is to Agree, we are working on making per-file key (PFK) driver generic to support any file system. > add a field in the bio structure which references a key id, and then > define a bdi-specific interface which allows the file system to > register a struct key and get a key id. Use of the key id will be > refcounted, so the device driver knows how many I/O operations are in > flight using a particular key --- since each ICE hardware will have a > different number of active keys that it can support. Understand the point here, we will consider this refcount while working on upstreamable PFK driver. > > Until that's there, at least for the upstream documentation, I think > it would be better to drop mention of code that is not yet upstream > --- and which may have problems ever going upstream in their current > form. Will clean the documentation. > > (I haven't checked in a while, but last time I looked the code in > question blindly dereferenced private pointers assuming that the only > two file systems that could ever use ICE were ext4 and f2fs.... not > that the code used by Google handsets were _that_ much cleaner, but > at least we dropped in a crypto key into the struct bio, instead of > playing unnatural games with private pointers from the wrong > abstraction layer. :-) before upstreaming the PFK drivers, we will try to avoid private pointer dereferences to achieve better abstraction to file system. > > - Ted
next prev parent reply other threads:[~2018-10-24 12:05 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-17 15:17 [PATCH 0/3] Add Inline Crypto Engine (ICE) driver AnilKumar Chimata 2018-10-17 15:17 ` [PATCH 1/3] firmware: qcom: scm: Update qcom_scm_call signature AnilKumar Chimata 2018-10-17 15:17 ` [PATCH 2/3] dt-bindings: Add ICE device specific parameters AnilKumar Chimata 2018-10-25 18:15 ` Rob Herring 2018-10-29 13:30 ` AnilKumar Chimata 2018-10-17 15:17 ` [PATCH 3/3] crypto: qce: ice: Add support for Inline Crypto Engine AnilKumar Chimata 2018-10-17 17:04 ` Theodore Y. Ts'o 2018-10-24 12:04 ` AnilKumar Chimata [this message] 2018-10-17 17:39 ` Randy Dunlap 2018-10-24 14:43 ` AnilKumar Chimata 2018-10-18 11:43 ` kbuild test robot 2018-10-24 11:14 ` anilc 2018-10-25 14:58 ` Rob Herring 2018-10-29 13:31 ` AnilKumar Chimata 2018-10-25 14:55 ` Rob Herring 2018-10-25 15:28 ` Theodore Y. Ts'o 2018-10-25 15:45 ` Rob Herring 2018-10-29 13:47 ` AnilKumar Chimata
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 3/3] crypto: qce: ice: Add support for Inline Crypto Engine' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).