From: Satya Tangirala <satyat@google.com>
To: Jens Axboe <axboe@kernel.dk>, boojin.kim@samsung.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>, Chao Yu <chao@kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
dm-devel@redhat.com, Mike Snitzer <snitzer@redhat.com>,
Alasdair Kergon <agk@redhat.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Kukjin Kim <kgene@kernel.org>,
Jaehoon Chung <jh80.chung@samsung.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-crypto@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 5/9] block: support diskcipher
Date: Thu, 22 Aug 2019 19:35:16 -0700 [thread overview]
Message-ID: <CAA+FYZc6G0xk7Dhx0b9xNRoK+b+DpfuS+OK4wn4bpKpFPiiGUQ@mail.gmail.com> (raw)
In-Reply-To: <6ea5e5db-4dd4-719f-3b3e-b89099636ea6@kernel.dk>
On Wed, Aug 21, 2019 at 5:10 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 8/21/19 12:42 AM, boojin.kim wrote:
> > This patch supports crypto information to be maintained via BIO
> > and passed to the storage driver.
> >
> > To do this, 'bi_aux_private', 'REQ_CYPTE' and 'bi_dun' are added
> > to the block layer.
> >
> > 'bi_aux_private' is added for loading additional private information into
> > BIO.
> > 'REQ_CRYPT' is added to distinguish that bi_aux_private is being used
> > for diskcipher.
> > F2FS among encryption users uses DUN(device unit number) as
> > the IV(initial vector) for cryptographic operations.
> > DUN is stored in 'bi_dun' of bi_iter as a specific value for each BIO.
> >
> > Before attempting to merge the two BIOs, the operation is also added to
> > verify that the crypto information contained in two BIOs is consistent.
>
> This isn't going to happen. With this, and the inline encryption
> proposed by Google, we'll bloat the bio even more. At least the Google
> approach didn't include bio iter changes as well.
>
> Please work it out between yourselves so we can have a single, clean
> abstraction that works for both.
>
> --
> Jens Axboe
>
Hi Boojin,
We're very keen to make sure that our approach to inline encryption can
work with diverse hardware, including Samsung's FMP hardware; if you
can see any issues with using our approach with your hardware please
let us know.
We understand that a possible concern for getting FMP working with our
patch series for Inline Encryption Support at
https://lore.kernel.org/linux-block/20190821075714.65140-1-satyat@google.com/
is that unlike some inline encryption hardware (and also unlike the JEDEC
UFS v2.1 spec), FMP doesn't have the concept of a limited number of
keyslots - to address that difference we have a "passthrough keyslot
manager", which we put up on top of our patch series for inline encryption
support at
https://android-review.googlesource.com/c/kernel/common/+/980137/2
Setting up a passthrough keyslot manager in the request queue of a
device allows the device to receive a bio's encryption context as-is with
the bio, which is what FMP would prefer. Are there any issues with
using the passthrough keyslot manager for FMP?
Thanks!
Satya
WARNING: multiple messages have this Message-ID (diff)
From: Satya Tangirala <satyat@google.com>
To: Jens Axboe <axboe@kernel.dk>, boojin.kim@samsung.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>, Chao Yu <chao@kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
dm-devel@redhat.com, Mike Snitzer <snitzer@redhat.com>,
Alasdair Kergon <agk@redhat.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Kukjin Kim <kgene@kernel.org>,
Jaehoon Chung <jh80.chung@samsung.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-crypto@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, linux-arm-kernel@list
Subject: Re: [PATCH 5/9] block: support diskcipher
Date: Thu, 22 Aug 2019 19:35:16 -0700 [thread overview]
Message-ID: <CAA+FYZc6G0xk7Dhx0b9xNRoK+b+DpfuS+OK4wn4bpKpFPiiGUQ@mail.gmail.com> (raw)
In-Reply-To: <6ea5e5db-4dd4-719f-3b3e-b89099636ea6@kernel.dk>
On Wed, Aug 21, 2019 at 5:10 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 8/21/19 12:42 AM, boojin.kim wrote:
> > This patch supports crypto information to be maintained via BIO
> > and passed to the storage driver.
> >
> > To do this, 'bi_aux_private', 'REQ_CYPTE' and 'bi_dun' are added
> > to the block layer.
> >
> > 'bi_aux_private' is added for loading additional private information into
> > BIO.
> > 'REQ_CRYPT' is added to distinguish that bi_aux_private is being used
> > for diskcipher.
> > F2FS among encryption users uses DUN(device unit number) as
> > the IV(initial vector) for cryptographic operations.
> > DUN is stored in 'bi_dun' of bi_iter as a specific value for each BIO.
> >
> > Before attempting to merge the two BIOs, the operation is also added to
> > verify that the crypto information contained in two BIOs is consistent.
>
> This isn't going to happen. With this, and the inline encryption
> proposed by Google, we'll bloat the bio even more. At least the Google
> approach didn't include bio iter changes as well.
>
> Please work it out between yourselves so we can have a single, clean
> abstraction that works for both.
>
> --
> Jens Axboe
>
Hi Boojin,
We're very keen to make sure that our approach to inline encryption can
work with diverse hardware, including Samsung's FMP hardware; if you
can see any issues with using our approach with your hardware please
let us know.
We understand that a possible concern for getting FMP working with our
patch series for Inline Encryption Support at
https://lore.kernel.org/linux-block/20190821075714.65140-1-satyat@google.com/
is that unlike some inline encryption hardware (and also unlike the JEDEC
UFS v2.1 spec), FMP doesn't have the concept of a limited number of
keyslots - to address that difference we have a "passthrough keyslot
manager", which we put up on top of our patch series for inline encryption
support at
https://android-review.googlesource.com/c/kernel/common/+/980137/2
Setting up a passthrough keyslot manager in the request queue of a
device allows the device to receive a bio's encryption context as-is with
the bio, which is what FMP would prefer. Are there any issues with
using the passthrough keyslot manager for FMP?
Thanks!
Satya
WARNING: multiple messages have this Message-ID (diff)
From: Satya Tangirala via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Jens Axboe <axboe@kernel.dk>, boojin.kim@samsung.com
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Andreas Dilger <adilger.kernel@dilger.ca>,
Alasdair Kergon <agk@redhat.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Krzysztof Kozlowski <krzk@kernel.org>,
Eric Biggers <ebiggers@kernel.org>, Kukjin Kim <kgene@kernel.org>,
linux-ext4@vger.kernel.org, linux-block@vger.kernel.org,
linux-fscrypt@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-arm-kernel@lists.infradead.org,
"Theodore Y. Ts'o" <tytso@mit.edu>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [f2fs-dev] [PATCH 5/9] block: support diskcipher
Date: Thu, 22 Aug 2019 19:35:16 -0700 [thread overview]
Message-ID: <CAA+FYZc6G0xk7Dhx0b9xNRoK+b+DpfuS+OK4wn4bpKpFPiiGUQ@mail.gmail.com> (raw)
In-Reply-To: <6ea5e5db-4dd4-719f-3b3e-b89099636ea6@kernel.dk>
On Wed, Aug 21, 2019 at 5:10 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 8/21/19 12:42 AM, boojin.kim wrote:
> > This patch supports crypto information to be maintained via BIO
> > and passed to the storage driver.
> >
> > To do this, 'bi_aux_private', 'REQ_CYPTE' and 'bi_dun' are added
> > to the block layer.
> >
> > 'bi_aux_private' is added for loading additional private information into
> > BIO.
> > 'REQ_CRYPT' is added to distinguish that bi_aux_private is being used
> > for diskcipher.
> > F2FS among encryption users uses DUN(device unit number) as
> > the IV(initial vector) for cryptographic operations.
> > DUN is stored in 'bi_dun' of bi_iter as a specific value for each BIO.
> >
> > Before attempting to merge the two BIOs, the operation is also added to
> > verify that the crypto information contained in two BIOs is consistent.
>
> This isn't going to happen. With this, and the inline encryption
> proposed by Google, we'll bloat the bio even more. At least the Google
> approach didn't include bio iter changes as well.
>
> Please work it out between yourselves so we can have a single, clean
> abstraction that works for both.
>
> --
> Jens Axboe
>
Hi Boojin,
We're very keen to make sure that our approach to inline encryption can
work with diverse hardware, including Samsung's FMP hardware; if you
can see any issues with using our approach with your hardware please
let us know.
We understand that a possible concern for getting FMP working with our
patch series for Inline Encryption Support at
https://lore.kernel.org/linux-block/20190821075714.65140-1-satyat@google.com/
is that unlike some inline encryption hardware (and also unlike the JEDEC
UFS v2.1 spec), FMP doesn't have the concept of a limited number of
keyslots - to address that difference we have a "passthrough keyslot
manager", which we put up on top of our patch series for inline encryption
support at
https://android-review.googlesource.com/c/kernel/common/+/980137/2
Setting up a passthrough keyslot manager in the request queue of a
device allows the device to receive a bio's encryption context as-is with
the bio, which is what FMP would prefer. Are there any issues with
using the passthrough keyslot manager for FMP?
Thanks!
Satya
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Satya Tangirala <satyat@google.com>
To: Jens Axboe <axboe@kernel.dk>, boojin.kim@samsung.com
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Andreas Dilger <adilger.kernel@dilger.ca>,
Alasdair Kergon <agk@redhat.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Krzysztof Kozlowski <krzk@kernel.org>,
Eric Biggers <ebiggers@kernel.org>, Kukjin Kim <kgene@kernel.org>,
linux-ext4@vger.kernel.org, Chao Yu <chao@kernel.org>,
linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-arm-kernel@lists.infradead.org,
"Theodore Y. Ts'o" <tytso@mit.edu>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 5/9] block: support diskcipher
Date: Thu, 22 Aug 2019 19:35:16 -0700 [thread overview]
Message-ID: <CAA+FYZc6G0xk7Dhx0b9xNRoK+b+DpfuS+OK4wn4bpKpFPiiGUQ@mail.gmail.com> (raw)
In-Reply-To: <6ea5e5db-4dd4-719f-3b3e-b89099636ea6@kernel.dk>
On Wed, Aug 21, 2019 at 5:10 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 8/21/19 12:42 AM, boojin.kim wrote:
> > This patch supports crypto information to be maintained via BIO
> > and passed to the storage driver.
> >
> > To do this, 'bi_aux_private', 'REQ_CYPTE' and 'bi_dun' are added
> > to the block layer.
> >
> > 'bi_aux_private' is added for loading additional private information into
> > BIO.
> > 'REQ_CRYPT' is added to distinguish that bi_aux_private is being used
> > for diskcipher.
> > F2FS among encryption users uses DUN(device unit number) as
> > the IV(initial vector) for cryptographic operations.
> > DUN is stored in 'bi_dun' of bi_iter as a specific value for each BIO.
> >
> > Before attempting to merge the two BIOs, the operation is also added to
> > verify that the crypto information contained in two BIOs is consistent.
>
> This isn't going to happen. With this, and the inline encryption
> proposed by Google, we'll bloat the bio even more. At least the Google
> approach didn't include bio iter changes as well.
>
> Please work it out between yourselves so we can have a single, clean
> abstraction that works for both.
>
> --
> Jens Axboe
>
Hi Boojin,
We're very keen to make sure that our approach to inline encryption can
work with diverse hardware, including Samsung's FMP hardware; if you
can see any issues with using our approach with your hardware please
let us know.
We understand that a possible concern for getting FMP working with our
patch series for Inline Encryption Support at
https://lore.kernel.org/linux-block/20190821075714.65140-1-satyat@google.com/
is that unlike some inline encryption hardware (and also unlike the JEDEC
UFS v2.1 spec), FMP doesn't have the concept of a limited number of
keyslots - to address that difference we have a "passthrough keyslot
manager", which we put up on top of our patch series for inline encryption
support at
https://android-review.googlesource.com/c/kernel/common/+/980137/2
Setting up a passthrough keyslot manager in the request queue of a
device allows the device to receive a bio's encryption context as-is with
the bio, which is what FMP would prefer. Are there any issues with
using the passthrough keyslot manager for FMP?
Thanks!
Satya
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-23 2:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190821064226epcas2p2835b8a9084988b79107e54abfc5e7dab@epcas2p2.samsung.com>
2019-08-21 6:42 ` [PATCH 5/9] block: support diskcipher boojin.kim
2019-08-21 6:42 ` boojin.kim
2019-08-21 6:42 ` [f2fs-dev] " boojin.kim
2019-08-21 6:42 ` boojin.kim
2019-08-21 6:42 ` boojin.kim
2019-08-21 12:09 ` Jens Axboe
2019-08-21 12:09 ` Jens Axboe
2019-08-21 12:09 ` [f2fs-dev] " Jens Axboe
2019-08-21 12:09 ` Jens Axboe
2019-08-23 2:35 ` Satya Tangirala [this message]
2019-08-23 2:35 ` Satya Tangirala
2019-08-23 2:35 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-23 2:35 ` Satya Tangirala
[not found] <CGME20190822005438epcas2p337aba06b328cdcdd1549395f0bbcfdbc@epcas2p3.samsung.com>
2019-08-22 0:54 ` boojin.kim
2019-08-22 0:54 ` boojin.kim
2019-08-22 0:54 ` boojin.kim
2019-08-22 0:54 ` boojin.kim
[not found] <CGME20190827083334epcas2p115d479190b9a72c886f66569add78203@epcas2p1.samsung.com>
2019-08-27 8:33 ` boojin.kim
2019-08-27 8:33 ` boojin.kim
2019-08-27 8:33 ` boojin.kim
2019-08-27 8:33 ` boojin.kim
2019-08-27 16:40 ` Theodore Y. Ts'o
2019-08-27 16:40 ` Theodore Y. Ts'o
2019-08-27 16:40 ` Theodore Y. Ts'o
[not found] <CGME20190828022055epcas2p25525077d0a5a3fa5a2027bac06a10bc1@epcas2p2.samsung.com>
2019-08-28 2:20 ` boojin.kim
2019-08-28 2:20 ` boojin.kim
2019-08-28 2:20 ` boojin.kim
2019-08-28 2:20 ` boojin.kim
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 \
--in-reply-to=CAA+FYZc6G0xk7Dhx0b9xNRoK+b+DpfuS+OK4wn4bpKpFPiiGUQ@mail.gmail.com \
--to=satyat@google.com \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=boojin.kim@samsung.com \
--cc=chao@kernel.org \
--cc=davem@davemloft.net \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jaegeuk@kernel.org \
--cc=jh80.chung@samsung.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=tytso@mit.edu \
--cc=ulf.hansson@linaro.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.