On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote: > > > > > > > > > Is it possible to use both kind of keys when working on standard mode? > > > > > If not, it should be the user who selects what type of keys to be used. > > > > > Enforcing this via DT is not a way to go. > > > > > > > > > > > > > Unfortunately, that support is not there yet. When you say user, do > > > > you mean to have it as a filesystem mount option? > > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like > > > to be able to use either a hardware-wrapped key or a standard key. > > > > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies. > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based) > > I must admit, I mostly used dm-crypt beforehand, so I had to look at > fscrypt now. Some of my previous comments might not be fully > applicable. > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported) > > And specify policies (links to keys) for different folders. > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this > > > > information is needed when the modules are loaded. > > > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@xxxxxxxxxx > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c > > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped > > > keys. But the line doesn't specify that standard keys are not supported. > > > > > > > Those are capabilities that are read from the storage controller. However, wrapped keys > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming > > from the SoC. > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode. > > That is something we are internally working on, but not available yet. > > I'd say this is a significant obstacle, at least from my point of > view. I understand that the default might be to use hw-wrapped keys, > but it should be possible for the user to select non-HW keys if the > ability to recover the data is considered to be important. Note, I'm > really pointing to the user here, not to the system integrator. So > using DT property or specifying kernel arguments to switch between > these modes is not really an option. > > But I'd really love to hear some feedback from linux-security and/or > linux-fscrypt here. > > In my humble opinion the user should be able to specify that the key > is wrapped using the hardware KMK. Then if the hardware has already > started using the other kind of keys, it should be able to respond > with -EINVAL / whatever else. Then the user can evict previously > programmed key and program a desired one. > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted > > > keys mechanism (see security/keys/trusted-keys/). Could you please point > > > out why that's not the case? > > > > > > > I will evaluate this. > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee > > driver. The interface is through QCOM SCM driver. > > Note, this is just an API interface, see how it is implemented for the > CAAM hardware. > The problem is that this patchset was sent out without the patches that add the block and filesystem-level framework for hardware-wrapped inline encryption keys, which it depends on. So it's lacking context. The proposed framework can be found at https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@xxxxxxxxxx/T/#u As for why "trusted keys" aren't used, they just aren't helpful here. "Trusted keys" are based around a model where the kernel can request that keys be sealed and unsealed using a trust source, and the kernel gets access to the raw unsealed keys. Hardware-wrapped inline encryption keys use a different model where the kernel never gets access to the raw keys. They also have the concept of ephemeral wrapping which does not exist in "trusted keys". And they need to be properly integrated with the inline encryption framework in the block layer. - Eric
