| Message ID | 20200616015718.7812-1-longman@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm, treewide: Rename kzfree() to kfree_sensitive() | expand |
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > v4: > - Break out the memzero_explicit() change as suggested by Dan Carpenter > so that it can be backported to stable. > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > now as there can be a bit more discussion on what is best. It will be > introduced as a separate patch later on after this one is merged. To this larger audience and last week without reply: https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ Are there _any_ fastpath uses of kfree or vfree? Many patches have been posted recently to fix mispairings of specific types of alloc and free functions. To eliminate these mispairings at a runtime cost of four comparisons, should the kfree/vfree/kvfree/kfree_const functions be consolidated into a single kfree? Something like the below: void kfree(const void *addr) { if (is_kernel_rodata((unsigned long)addr)) return; if (is_vmalloc_addr(addr)) _vfree(addr); else _kfree(addr); } #define kvfree kfree #define vfree kfree #define kfree_const kfree
On 6/16/20 2:53 PM, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >> v4: >> - Break out the memzero_explicit() change as suggested by Dan Carpenter >> so that it can be backported to stable. >> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >> now as there can be a bit more discussion on what is best. It will be >> introduced as a separate patch later on after this one is merged. > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? I am not sure about that, but both of them can be slow. > > Many patches have been posted recently to fix mispairings > of specific types of alloc and free functions. > > To eliminate these mispairings at a runtime cost of four > comparisons, should the kfree/vfree/kvfree/kfree_const > functions be consolidated into a single kfree? > > Something like the below: > > void kfree(const void *addr) > { > if (is_kernel_rodata((unsigned long)addr)) > return; > > if (is_vmalloc_addr(addr)) > _vfree(addr); > else > _kfree(addr); > } > is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the overhead can be a bit bigger. Cheers, Longman
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches <joe@perches.com> wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > v4: > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > so that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a bit more discussion on what is best. It will be > > introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? The networking stack has various places where there will be a quick kmalloc followed by a kfree for an incoming or outgoing packet. One place that comes to mind would be esp_alloc_tmp, which does a quick allocation of some temporary kmalloc memory, processes some packet things inside of that, and then frees it, sometimes in the same function, and sometimes later in an async callback. I don't know how "fastpath" you consider this, but usually packet processing is something people want to do with minimal overhead, considering how fast NICs are these days.
On 6/16/20 2:53 PM, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >> v4: >> - Break out the memzero_explicit() change as suggested by Dan Carpenter >> so that it can be backported to stable. >> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >> now as there can be a bit more discussion on what is best. It will be >> introduced as a separate patch later on after this one is merged. > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? > > Many patches have been posted recently to fix mispairings > of specific types of alloc and free functions. > > To eliminate these mispairings at a runtime cost of four > comparisons, should the kfree/vfree/kvfree/kfree_const > functions be consolidated into a single kfree? > > Something like the below: > > void kfree(const void *addr) > { > if (is_kernel_rodata((unsigned long)addr)) > return; > > if (is_vmalloc_addr(addr)) > _vfree(addr); > else > _kfree(addr); > } > > #define kvfree kfree > #define vfree kfree > #define kfree_const kfree > > How about adding CONFIG_DEBUG_VM code to check for invalid address ranges in kfree() and vfree()? By doing this, we can catch unmatched pairing in debug mode, but won't have the overhead when debug mode is off. Thought? Cheers, Longman
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? I worked on adding a 'free' a couple of years ago. That was capable of freeing percpu, vmalloc, kmalloc and alloc_pages memory. I ran into trouble when I tried to free kmem_cache_alloc memory -- it works for slab and slub, but not slob (because slob needs the size from the kmem_cache). My motivation for this was to change kfree_rcu() to just free_rcu(). > To eliminate these mispairings at a runtime cost of four > comparisons, should the kfree/vfree/kvfree/kfree_const > functions be consolidated into a single kfree? I would say to leave kfree() alone and just introduce free() as a new default. There's some weird places in the kernel that have a 'free' symbol of their own, but those should be renamed anyway.
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > v4: > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > so that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a bit more discussion on what is best. It will be > > introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? I'd consider kfree performance critical for cases where it is called under locks. If possible the kfree is moved outside of the critical section, but we have rbtrees or lists that get deleted under locks and restructuring the code to do eg. splice and free it outside of the lock is not always possible.
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > > now as there can be a bit more discussion on what is best. It will be > > > introduced as a separate patch later on after this one is merged. > > > > To this larger audience and last week without reply: > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > > > Are there _any_ fastpath uses of kfree or vfree? > > I'd consider kfree performance critical for cases where it is called > under locks. If possible the kfree is moved outside of the critical > section, but we have rbtrees or lists that get deleted under locks and > restructuring the code to do eg. splice and free it outside of the lock > is not always possible. Not just performance critical, but correctness critical. Since kvfree() may allocate from the vmalloc allocator, I really think that kvfree() should assert that it's !in_atomic(). Otherwise we can get into trouble if we end up calling vfree() and have to take the mutex.
On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > > v4: > > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > > so that it can be backported to stable. > > > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > > > now as there can be a bit more discussion on what is best. It will be > > > > introduced as a separate patch later on after this one is merged. > > > > > > To this larger audience and last week without reply: > > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > > > > > Are there _any_ fastpath uses of kfree or vfree? > > > > I'd consider kfree performance critical for cases where it is called > > under locks. If possible the kfree is moved outside of the critical > > section, but we have rbtrees or lists that get deleted under locks and > > restructuring the code to do eg. splice and free it outside of the lock > > is not always possible. > > Not just performance critical, but correctness critical. Since kvfree() > may allocate from the vmalloc allocator, I really think that kvfree() > should assert that it's !in_atomic(). Otherwise we can get into trouble > if we end up calling vfree() and have to take the mutex. FWIW __vfree already checks for atomic context and put the work into a deferred context. So this should be safe. It should be used as a last resort, though.
Bonjour, Désolé, aucune traduction possible, En français pour comprendre! Merci slts > Le 17 06 2020 à 02:37, Matthew Wilcox <willy@infradead.org> a écrit : > > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: >> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: >>> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >>>> v4: >>>> - Break out the memzero_explicit() change as suggested by Dan Carpenter >>>> so that it can be backported to stable. >>>> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >>>> now as there can be a bit more discussion on what is best. It will be >>>> introduced as a separate patch later on after this one is merged. >>> >>> To this larger audience and last week without reply: >>> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ >>> >>> Are there _any_ fastpath uses of kfree or vfree? >> >> I'd consider kfree performance critical for cases where it is called >> under locks. If possible the kfree is moved outside of the critical >> section, but we have rbtrees or lists that get deleted under locks and >> restructuring the code to do eg. splice and free it outside of the lock >> is not always possible. > > Not just performance critical, but correctness critical. Since kvfree() > may allocate from the vmalloc allocator, I really think that kvfree() > should assert that it's !in_atomic(). Otherwise we can get into trouble > if we end up calling vfree() and have to take the mutex. Jo-l joel.voyer@gmail.com
On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > Not just performance critical, but correctness critical. Since kvfree() > > may allocate from the vmalloc allocator, I really think that kvfree() > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > if we end up calling vfree() and have to take the mutex. > > FWIW __vfree already checks for atomic context and put the work into a > deferred context. So this should be safe. It should be used as a last > resort, though. Actually, it only checks for in_interrupt(). If you call vfree() under a spinlock, you're in trouble. in_atomic() only knows if we hold a spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() in __vfree(). So we need the warning in order that preempt people can tell those without that there is a bug here.
On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the vmalloc allocator, I really think that kvfree() > > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > > if we end up calling vfree() and have to take the mutex. > > > > FWIW __vfree already checks for atomic context and put the work into a > > deferred context. So this should be safe. It should be used as a last > > resort, though. > > Actually, it only checks for in_interrupt(). You are right. I have misremembered. You have made me look (thanks) ... > If you call vfree() under > a spinlock, you're in trouble. in_atomic() only knows if we hold a > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > in __vfree(). So we need the warning in order that preempt people can > tell those without that there is a bug here. ... Unless I am missing something in_interrupt depends on preempt_count() as well so neither of the two is reliable without PREEMPT_COUNT configured.
On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > If you call vfree() under > > a spinlock, you're in trouble. in_atomic() only knows if we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can > > tell those without that there is a bug here. > > ... Unless I am missing something in_interrupt depends on preempt_count() as > well so neither of the two is reliable without PREEMPT_COUNT configured. preempt_count() always tracks whether we're in interrupt context, regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT will track spinlock acquisitions as well.
On Wed 17-06-20 05:23:21, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > > If you call vfree() under > > > a spinlock, you're in trouble. in_atomic() only knows if we hold a > > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > > in __vfree(). So we need the warning in order that preempt people can > > > tell those without that there is a bug here. > > > > ... Unless I am missing something in_interrupt depends on preempt_count() as > > well so neither of the two is reliable without PREEMPT_COUNT configured. > > preempt_count() always tracks whether we're in interrupt context, > regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT > will track spinlock acquisitions as well. Right you are! Thanks for the clarification. I find the situation around preempt_count quite confusing TBH. Looking at existing users of in_atomic() (e.g. a random one zd_usb_iowrite16v_async which check in_atomic and then does GFP_KERNEL allocation which would be obviously broken on !PREEMPT if the function can be called from an atomic context), I am wondering whether it would make sense to track atomic context also for !PREEMPT. This check is just terribly error prone.
On 6/16/20 9:53 PM, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >> v4: >> - Break out the memzero_explicit() change as suggested by Dan Carpenter >> so that it can be backported to stable. >> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >> now as there can be a bit more discussion on what is best. It will be >> introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? > > Many patches have been posted recently to fix mispairings > of specific types of alloc and free functions. I've prepared a coccinelle script to highlight these mispairings in a function a couple of days ago: https://lkml.org/lkml/2020/6/5/953 I've listed all the fixes in the commit message. Not so many mispairings actually, and most of them are harmless like: kmalloc(E) -> kvfree(E) However, coccinelle script can't detect cross-functions mispairings, i.e. allocation in one function, free in another funtion. Thanks, Denis
On Thu, 2020-06-18 at 00:31 +0300, Denis Efremov wrote: > > On 6/16/20 9:53 PM, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > > now as there can be a bit more discussion on what is best. It will be > > > introduced as a separate patch later on after this one is merged. > > > > To this larger audience and last week without reply: > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > > > Are there _any_ fastpath uses of kfree or vfree? > > > > Many patches have been posted recently to fix mispairings > > of specific types of alloc and free functions. > > I've prepared a coccinelle script to highlight these mispairings in a function > a couple of days ago: https://lkml.org/lkml/2020/6/5/953 > I've listed all the fixes in the commit message. > > Not so many mispairings actually, and most of them are harmless like: > kmalloc(E) -> kvfree(E) > > However, coccinelle script can't detect cross-functions mispairings, i.e. > allocation in one function, free in another funtion. Hey Denis, thanks for those patches. If possible, it's probably better to not require these pairings and use a single standard kfree/free function. Given the existing ifs in kfree in slab/slob/slub, it seems likely that adding a few more wouldn't have much impact.
v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer especially if LTO is used. Instead, the new kfree_sensitive() uses memzero_explicit() which won't get compiled out. Waiman Long (3): mm/slab: Use memzero_explicit() in kzfree() mm, treewide: Rename kzfree() to kfree_sensitive() btrfs: Use kfree() in btrfs_ioctl_get_subvol_info() arch/s390/crypto/prng.c | 4 +-- arch/x86/power/hibernate.c | 2 +- crypto/adiantum.c | 2 +- crypto/ahash.c | 4 +-- crypto/api.c | 2 +- crypto/asymmetric_keys/verify_pefile.c | 4 +-- crypto/deflate.c | 2 +- crypto/drbg.c | 10 +++--- crypto/ecc.c | 8 ++--- crypto/ecdh.c | 2 +- crypto/gcm.c | 2 +- crypto/gf128mul.c | 4 +-- crypto/jitterentropy-kcapi.c | 2 +- crypto/rng.c | 2 +- crypto/rsa-pkcs1pad.c | 6 ++-- crypto/seqiv.c | 2 +- crypto/shash.c | 2 +- crypto/skcipher.c | 2 +- crypto/testmgr.c | 6 ++-- crypto/zstd.c | 2 +- .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 2 +- .../allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +- drivers/crypto/amlogic/amlogic-gxl-cipher.c | 4 +-- drivers/crypto/atmel-ecc.c | 2 +- drivers/crypto/caam/caampkc.c | 28 +++++++-------- drivers/crypto/cavium/cpt/cptvf_main.c | 6 ++-- drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 12 +++---- drivers/crypto/cavium/nitrox/nitrox_lib.c | 4 +-- drivers/crypto/cavium/zip/zip_crypto.c | 6 ++-- drivers/crypto/ccp/ccp-crypto-rsa.c | 6 ++-- drivers/crypto/ccree/cc_aead.c | 4 +-- drivers/crypto/ccree/cc_buffer_mgr.c | 4 +-- drivers/crypto/ccree/cc_cipher.c | 6 ++-- drivers/crypto/ccree/cc_hash.c | 8 ++--- drivers/crypto/ccree/cc_request_mgr.c | 2 +- drivers/crypto/marvell/cesa/hash.c | 2 +- .../crypto/marvell/octeontx/otx_cptvf_main.c | 6 ++-- .../marvell/octeontx/otx_cptvf_reqmgr.h | 2 +- drivers/crypto/mediatek/mtk-aes.c | 2 +- drivers/crypto/nx/nx.c | 4 +-- drivers/crypto/virtio/virtio_crypto_algs.c | 12 +++---- drivers/crypto/virtio/virtio_crypto_core.c | 2 +- drivers/md/dm-crypt.c | 32 ++++++++--------- drivers/md/dm-integrity.c | 6 ++-- drivers/misc/ibmvmc.c | 6 ++-- .../hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +- .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 ++-- drivers/net/ppp/ppp_mppe.c | 6 ++-- drivers/net/wireguard/noise.c | 4 +-- drivers/net/wireguard/peer.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 6 ++-- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 6 ++-- drivers/net/wireless/intersil/orinoco/wext.c | 4 +-- drivers/s390/crypto/ap_bus.h | 4 +-- drivers/staging/ks7010/ks_hostif.c | 2 +- drivers/staging/rtl8723bs/core/rtw_security.c | 2 +- drivers/staging/wlan-ng/p80211netdev.c | 2 +- drivers/target/iscsi/iscsi_target_auth.c | 2 +- fs/btrfs/ioctl.c | 2 +- fs/cifs/cifsencrypt.c | 2 +- fs/cifs/connect.c | 10 +++--- fs/cifs/dfs_cache.c | 2 +- fs/cifs/misc.c | 8 ++--- fs/crypto/keyring.c | 6 ++-- fs/crypto/keysetup_v1.c | 4 +-- fs/ecryptfs/keystore.c | 4 +-- fs/ecryptfs/messaging.c | 2 +- include/crypto/aead.h | 2 +- include/crypto/akcipher.h | 2 +- include/crypto/gf128mul.h | 2 +- include/crypto/hash.h | 2 +- include/crypto/internal/acompress.h | 2 +- include/crypto/kpp.h | 2 +- include/crypto/skcipher.h | 2 +- include/linux/slab.h | 2 +- lib/mpi/mpiutil.c | 6 ++-- lib/test_kasan.c | 6 ++-- mm/slab_common.c | 10 +++--- net/atm/mpoa_caches.c | 4 +-- net/bluetooth/ecdh_helper.c | 6 ++-- net/bluetooth/smp.c | 24 ++++++------- net/core/sock.c | 2 +- net/ipv4/tcp_fastopen.c | 2 +- net/mac80211/aead_api.c | 4 +-- net/mac80211/aes_gmac.c | 2 +- net/mac80211/key.c | 2 +- net/mac802154/llsec.c | 20 +++++------ net/sctp/auth.c | 2 +- net/sctp/socket.c | 2 +- net/sunrpc/auth_gss/gss_krb5_crypto.c | 4 +-- net/sunrpc/auth_gss/gss_krb5_keys.c | 6 ++-- net/sunrpc/auth_gss/gss_krb5_mech.c | 2 +- net/tipc/crypto.c | 10 +++--- net/wireless/core.c | 2 +- net/wireless/ibss.c | 4 +-- net/wireless/lib80211_crypt_tkip.c | 2 +- net/wireless/lib80211_crypt_wep.c | 2 +- net/wireless/nl80211.c | 24 ++++++------- net/wireless/sme.c | 6 ++-- net/wireless/util.c | 2 +- net/wireless/wext-sme.c | 2 +- scripts/coccinelle/free/devm_free.cocci | 4 +-- scripts/coccinelle/free/ifnullfree.cocci | 4 +-- scripts/coccinelle/free/kfree.cocci | 6 ++-- scripts/coccinelle/free/kfreeaddr.cocci | 2 +- security/apparmor/domain.c | 4 +-- security/apparmor/include/file.h | 2 +- security/apparmor/policy.c | 24 ++++++------- security/apparmor/policy_ns.c | 6 ++-- security/apparmor/policy_unpack.c | 14 ++++---- security/keys/big_key.c | 6 ++-- security/keys/dh.c | 14 ++++---- security/keys/encrypted-keys/encrypted.c | 14 ++++---- security/keys/trusted-keys/trusted_tpm1.c | 34 +++++++++---------- security/keys/user_defined.c | 6 ++-- 116 files changed, 322 insertions(+), 322 deletions(-)