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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 Aug 2019 12:40:12 -0400 From: "Theodore Y. Ts'o" <tytso@....edu> To: "boojin.kim" <boojin.kim@...sung.com> Cc: "'Satya Tangirala'" <satyat@...gle.com>, "'Herbert Xu'" <herbert@...dor.apana.org.au>, "'David S. Miller'" <davem@...emloft.net>, "'Eric Biggers'" <ebiggers@...nel.org>, "'Chao Yu'" <chao@...nel.org>, "'Jaegeuk Kim'" <jaegeuk@...nel.org>, "'Andreas Dilger'" <adilger.kernel@...ger.ca>, dm-devel@...hat.com, "'Mike Snitzer'" <snitzer@...hat.com>, "'Alasdair Kergon'" <agk@...hat.com>, "'Jens Axboe'" <axboe@...nel.dk>, "'Krzysztof Kozlowski'" <krzk@...nel.org>, "'Kukjin Kim'" <kgene@...nel.org>, "'Jaehoon Chung'" <jh80.chung@...sung.com>, "'Ulf Hansson'" <ulf.hansson@...aro.org>, linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fscrypt@...r.kernel.org, linux-mmc@...r.kernel.org, linux-samsung-soc@...r.kernel.org, linux-block@...r.kernel.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-arm-kernel@...ts.infradead.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH 5/9] block: support diskcipher On Tue, Aug 27, 2019 at 05:33:33PM +0900, boojin.kim wrote: > > Dear Satya. > Keyslot manager is a good solution for ICE. And probably no issue for FMP. > But, I think it's complicated for FMP because FMP doesn't need > any keyslot control. Hi Boojin, I think the important thing to realize here is that there are a large number of hardware devices for which the keyslot manager *is* needed. And from the upstream kernel's perspective, supporting two different schemes for supporting the inline encryption feature is more complexity than just supporting one which is general enough to support a wider variety of hardware devices. If you want somethig which is only good for the hardware platform you are charged to support, that's fine if it's only going to be in a Samsung-specific kernel. But if your goal is to get something that works upstream, especially if it requires changes in core layers of the kernel, it's important that it's general enough to support most, if not all, if the hardware devices in the industry. Regards, - Ted
Powered by blists - more mailing lists