This repository was archived by the owner on Nov 11, 2024. It is now read-only.
Dnt - #31
Open
zhouji3x wants to merge 27 commits into
Open
Conversation
Change-Id: I96bca3c89a800df921b921f157dd23d0b3234a5a Tracked-On: Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
Change-Id: I6a89e81ca93cabd8a35848ebe61c2a29ad928738 Tracked-On: Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Remove Android.mk as redefine errors are seen when multiple kernels projects are used in the Android build. Signed-off-by: Jeevaka Prabu Badrappan <jeevaka.badrappan@intel.com>
This driver is required if you want to use Bluetooth devices with USB interface to support SCO. Tracked-On: OAM-91225 Signed-off-by: Amalendu Prasad Das <amalendu.prasad.das@intel.com>
In some of the C922 camera devices, we find that GET_DEF request is not implemented for video probe and commit controls. These cameras crash when this request is received. Hence, add this quirk for C922 cameras. Tracked-On: OAM-91289 Signed-off-by: saranya <saranya.gopal@intel.com>
When GVT in chromium kernel is active, return true. that is: GVT-g --- true GVT-d --- false native --- false Tracked-On: OAM-91324 Signed-off-by: Shaofeng Tang <shaofeng.tang@intel.com>
In CML, "Schedule request retirement when timeline idles" might introduce random drm init failure during reboot. This change is to enable schedule request retirement on Gen10+ Tracked-On: OAM-91972 Signed-off-by: Romli, Khairul Anuar <khairul.anuar.romli@intel.com> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Signed-off-by: Shaofeng Tang <shaofeng.tang@intel.com>
Extend the FS_IOC_ADD_ENCRYPTION_KEY ioctl to allow the raw key to be specified by a Linux keyring key, rather than specified directly. This is useful because fscrypt keys belong to a particular filesystem instance, so they are destroyed when that filesystem is unmounted. Usually this is desired. But in some cases, userspace may need to unmount and re-mount the filesystem while keeping the keys, e.g. during a system update. This requires keeping the keys somewhere else too. The keys could be kept in memory in a userspace daemon. But depending on the security architecture and assumptions, it can be preferable to keep them only in kernel memory, where they are unreadable by userspace. We also can't solve this by going back to the original fscrypt API (where for each file, the master key was looked up in the process's keyring hierarchy) because that caused lots of problems of its own. Therefore, add the ability for FS_IOC_ADD_ENCRYPTION_KEY to accept a Linux keyring key. This solves the problem by allowing userspace to (if needed) save the keys securely in a Linux keyring for re-provisioning, while still using the new fscrypt key management ioctls. This is analogous to how dm-crypt accepts a Linux keyring key, but the key is then stored internally in the dm-crypt data structures rather than being looked up again each time the dm-crypt device is accessed. Use a custom key type "fscrypt-provisioning" rather than one of the existing key types such as "logon". This is strongly desired because it enforces that these keys are only usable for a particular purpose: for fscrypt as input to a particular KDF. Otherwise, the keys could also be passed to any kernel API that accepts a "logon" key with any service prefix, e.g. dm-crypt, UBIFS, or (recently proposed) AF_ALG. This would risk leaking information about the raw key despite it ostensibly being unreadable. Of course, this mistake has already been made for multiple kernel APIs; but since this is a new API, let's do it right. This patch has been tested using an xfstest which I wrote to test it. Link: https://lore.kernel.org/r/20191119222447.226853-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
Freezing of process abort when a client is waiting uninterruptibly for a response. This happens when system is entering to suspend and trying to freeze all the processes and at that moment freezing aborts which leads to suspend failure. So instead of wait_event_killable() use wait_event_freezable() Signed-off-by: Kaushlendra Kumar <kaushalendra.kumar@intel.com>
Adding vendor command support for querying driver & firmware version. Tracked-On: OAM-94267 Signed-off-by: Jeevaka Prabu Badrappan <jeevaka.badrappan@intel.com> Signed-off-by: Amrita Raju <amrita.raju@intel.com>
Sometimes power button does not wake up the systemm, we get suspends event right after that. here Android needs to see KEY_POWER at resume. Otherwise, its opportunistic suspend will kick in shortly. However, other OS such as Ubuntu doesn't like KEY_POWER at resume. So add a knob "/sys/module/button/parameters/key_power_at_resume" for users to select. Tracked-On:
…eries Changes v5 => v6: - Blk-crypto's kernel crypto API fallback is no longer restricted to 8-byte DUNs. It's also now separately configurable from blk-crypto, and can be disabled entirely, while still allowing the kernel to use inline encryption hardware. Further, struct bio_crypt_ctx takes up less space, and no longer contains the information needed by the crypto API fallback - the fallback allocates the required memory when necessary. - Blk-crypto now supports all file content encryption modes supported by fscrypt. - Fixed bio merging logic in blk-merge.c - Fscrypt now supports inline encryption with the direct key policy, since blk-crypto now has support for larger DUNs. - Keyslot manager now uses a hashtable to lookup which keyslot contains any particular key (thanks Eric!) - Fscrypt support for inline encryption now handles filesystems with multiple underlying block devices (thanks Eric!) - Numerous cleanups Bug: 137270441 Test: refer to I26376479ee38259b8c35732cb3a1d7e15f9b05a3 Change-Id: I13e2e327e0b4784b394cb1e7cf32a04856d95f01 Link: https://lore.kernel.org/linux-block/20191218145136.172774-1-satyat@google.com/ Signed-off-by: Satya Tangirala <satyat@google.com>
While we're waiting for v7 of the inline crypto patchset, fix some bugs that made it into the v6 patchset, including one that caused bios with an encryption context to never be merged, and one that could cause non-contiguous pages to incorrectly added to a bio. Bug: 137270441 Change-Id: I3911fcd6c76b5c9063b86d6af6267ad990a46718 Signed-off-by: Eric Biggers <ebiggers@google.com>
Export the blk-crypto symbols needed for modules to use inline crypto. These would have already been exported, except that so far they've only been used by fs/crypto/, which is no longer modular. Bug: 137270441 Bug: 147814592 Change-Id: I64bf98aecabe891c188b30dd50124aacb1e008ca Signed-off-by: Eric Biggers <ebiggers@google.com>
On Snapdragon SoCs, the Linux kernel isn't permitted to directly access the standard UFS crypto configuration registers. Instead, programming and evicting keys must be done through vendor-specific SMC calls. To support this hardware, add a ->program_key() method to 'struct ufs_hba_variant_ops'. This allows overriding the UFS standard key programming procedure. Link: https://lore.kernel.org/r/20200110061634.46742-5-ebiggers@kernel.org Bug: 137270441 Bug: 147259927 Change-Id: Ia561d5a51421baaf78de52a1eaec496093a0d0ad Signed-off-by: Eric Biggers <ebiggers@google.com>
ext4 and f2fs have traditionally not supported direct I/O on encrypted files, since it's difficult to implement with the traditional filesystem-layer encryption. But when inline encryption is used instead, it's straightforward to support direct I/O, as long as the I/O is fully filesystem-block-aligned. Add support for it by: - Making the two generic direct I/O implementations in the kernel, __blockdev_direct_IO() and iomap_dio_rw(), set the encryption context on bios for inline-encrypted files. __blockdev_direct_IO() is used by f2fs, and was used by ext4 in kernel v5.4 and earlier. iomap_dio_rw() is used by ext4 in kernel v5.5 and later. - Making ext4 and f2fs allow direct I/O to encrypted files (rather the current behavior of falling back to buffered I/O) when the file is using inline encryption and the I/O is fully filesystem-block-aligned. Bug: 137270441 Change-Id: I4c8f7497eb8f829d03611d24281113d68c21d4d1 Signed-off-by: Eric Biggers <ebiggers@google.com>
The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
Update the device-mapper core to support exposing the inline crypto support of the underlying device(s) through the device-mapper device. This works by creating a "passthrough keyslot manager" for the dm device, which declares support for the set of (crypto_mode, data_unit_size) combos which all the underlying devices support. When a supported combo is used, the bio cloning code handles cloning the crypto context to the bios for all the underlying devices. When an unsupported combo is used, the blk-crypto fallback is used as usual. Crypto support on each underlying device is ignored unless the corresponding dm target opts into exposing it. This is needed because for inline crypto to semantically operate on the original bio, the data must not be transformed by the dm target. Thus, targets like dm-linear can expose crypto support of the underlying device, but targets like dm-crypt can't. (dm-crypt could use inline crypto itself, though.) When a key is evicted from the dm device, it is evicted from all underlying devices. Bug: 137270441 Bug: 147814592 Change-Id: If28b574f2e28268db5eb9f325d4cf8f96cb63e3f Signed-off-by: Eric Biggers <ebiggers@google.com>
dm-linear obviously can pass through inline crypto support. In addition, we need dm-bow to pass through inline crypto support, as the userdata partition in Android may be located on top of dm-bow. Bug: 137270441 Change-Id: Ib9b0f67b77391fa450394568ceed441c1508de6e Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a device-mapper target "dm-default-key" which assigns an encryption key to bios that aren't for the contents of an encrypted file. This ensures that all blocks on-disk will be encrypted with some key, without the performance hit of file contents being encrypted twice when fscrypt (File-Based Encryption) is used. It is only appropriate to use dm-default-key when key configuration is tightly controlled, like it is in Android, such that all fscrypt keys are at least as hard to compromise as the default key. Compared to the original version of dm-default-key, this has been modified to use the new vendor-independent inline encryption framework (which works even when no inline encryption hardware is present), the table syntax has been changed to match dm-crypt, and support for specifying Adiantum encryption has been added. These changes also mean that dm-default-key now always explicitly specifies the DUN (the IV). Also, to handle f2fs moving blocks of encrypted files around without the key, and to handle ext4 and f2fs filesystems mounted without '-o inlinecrypt', the mapping logic is no longer "set a key on the bio if it doesn't have one already", but rather "set a key on the bio unless the bio has the bi_skip_dm_default_key flag set". Filesystems set this flag on *all* bios for encrypted file contents, regardless of whether they are encrypting/decrypting the file using inline encryption or the traditional filesystem-layer encryption, or moving the raw data. For the bi_skip_dm_default_key flag, a new field in struct bio is used rather than a bit in bi_opf so that fscrypt_set_bio_crypt_ctx() can set the flag, minimizing the changes needed to filesystems. (bi_opf is usually overwritten after fscrypt_set_bio_crypt_ctx() is called.) Bug: 137270441 Bug: 147814592 Change-Id: I69c9cd1e968ccf990e4ad96e5115b662237f5095 Signed-off-by: Eric Biggers <ebiggers@google.com>
Currently, blk-crypto uses the algorithm to determine the size of keys. However, some inline encryption hardware supports protecting keys from software by wrapping the storage keys with an ephemeral key. Since these wrapped keys are not of a fixed size, add the capability to provide the key size when initializing a blk_crypto_key, and update the keyslot manager to take size into account when comparing keys. Bug: 147209885 Change-Id: Ibc2e4807e0a0ec473e72d131e0f20abb3a6033b5 Co-developed-by: Gaurav Kashyap <gaurkash@codeaurora.org> Signed-off-by: Gaurav Kashyap <gaurkash@codeaurora.org> Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org> Signed-off-by: Eric Biggers <ebiggers@google.com>
While dm-default-key no longer requires that the filesystem is also
using inline encryption (i.e. mounted with '-o inlinecrypt'), it does
still rely on the inline crypto hooks like fscrypt_set_bio_crypt_ctx()
being built into the kernel rather than stubbed out, as these are used
to set the bi_skip_dm_default_key flag on bios for encrypted files.
I.e., CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y is still needed.
The proper solution is to fix these hooks to handle DM_DEFAULT_KEY &&
!FS_ENCRYPTION_INLINE_CRYPT, but that would introduce a case that
wouldn't get tested. So for now, to avoid problems just make
dm-default-key depend on FS_ENCRYPTION_INLINE_CRYPT.
Test: make gki_defconfig
echo CONFIG_FS_ENCRYPTION_INLINE_CRYPT=n >> .config
make olddefconfig
grep CONFIG_DM_DEFAULT_KEY .config # was disabled
Bug: 147814592
Change-Id: Ie52686a72d5d14457d87dcf81677e33e291680bb
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a statx attribute bit STATX_ATTR_VERITY which will be set if the file has fs-verity enabled. This is the statx() equivalent of FS_VERITY_FL which is returned by FS_IOC_GETFLAGS. This is useful because it allows applications to check whether a file is a verity file without opening it. Opening a verity file can be expensive because the fsverity_info is set up on open, which involves parsing metadata and optionally verifying a cryptographic signature. This is analogous to how various other bits are exposed through both FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit. Reviewed-by: Andreas Dilger <adilger@dilger.ca> Acked-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
Set the STATX_ATTR_VERITY bit when the statx() system call is used on a verity file on ext4. Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Eric Biggers <ebiggers@google.com>
Set the STATX_ATTR_VERITY bit when the statx() system call is used on a verity file on f2fs. Signed-off-by: Eric Biggers <ebiggers@google.com>
Tracked-On: Signed-off-by: JianFeng,Zhou <jianfeng.zhou@intel.com>
JeevakaPrabu
referenced
this pull request
in projectceladon-ci/linux-intel-lts2019-chromium
Aug 5, 2021
commit 16a200f66ede3f9afa2e51d90ade017aaa18d213 upstream. A fstrim on a degraded raid1 can trigger the following null pointer dereference: BTRFS info (device loop0): allowing degraded mounts BTRFS info (device loop0): disk space caching is enabled BTRFS info (device loop0): has skinny extents BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing BTRFS info (device loop0): enabling ssd optimizations BUG: kernel NULL pointer dereference, address: 0000000000000620 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 4574 Comm: fstrim Not tainted 5.13.0-rc7+ #31 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 RIP: 0010:btrfs_trim_fs+0x199/0x4a0 [btrfs] RSP: 0018:ffff959541797d28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff946f84eca508 RCX: a7a67937adff8608 RDX: ffff946e8122d000 RSI: 0000000000000000 RDI: ffffffffc02fdbf0 RBP: ffff946ea4615000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: ffff946e8122d960 R12: 0000000000000000 R13: ffff959541797db8 R14: ffff946e8122d000 R15: ffff959541797db8 FS: 00007f55917a5080(0000) GS:ffff946f9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000620 CR3: 000000002d2c8001 CR4: 00000000000706f0 Call Trace: btrfs_ioctl_fitrim+0x167/0x260 [btrfs] btrfs_ioctl+0x1c00/0x2fe0 [btrfs] ? selinux_file_ioctl+0x140/0x240 ? syscall_trace_enter.constprop.0+0x188/0x240 ? __x64_sys_ioctl+0x83/0xb0 __x64_sys_ioctl+0x83/0xb0 Reproducer: $ mkfs.btrfs -fq -d raid1 -m raid1 /dev/loop0 /dev/loop1 $ mount /dev/loop0 /btrfs $ umount /btrfs $ btrfs dev scan --forget $ mount -o degraded /dev/loop0 /btrfs $ fstrim /btrfs The reason is we call btrfs_trim_free_extents() for the missing device, which uses device->bdev (NULL for missing device) to find if the device supports discard. Fix is to check if the device is missing before calling btrfs_trim_free_extents(). CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lakshmishreec
referenced
this pull request
in lakshmishreec/linux-intel-lts2019-chromium
Oct 14, 2021
[ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ] uart_handle_dcd_change() requires a port lock to be held and will emit a warning when lockdep is enabled. Held corresponding lock to fix the following warnings. [ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120 [ 132.530482] Modules linked in: [ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty projectceladon-ci#31 [ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120 [ 132.557100] Call Trace: [ 132.557562] ? __free_pages+0x83/0xb0 [ 132.558213] neo_parse_modem+0x156/0x220 [ 132.558897] neo_param+0x399/0x840 [ 132.559495] jsm_tty_open+0x12f/0x2d0 [ 132.560131] uart_startup.part.18+0x153/0x340 [ 132.560888] ? lock_is_held_type+0xe9/0x140 [ 132.561660] uart_port_activate+0x7f/0xe0 [ 132.562351] ? uart_startup.part.18+0x340/0x340 [ 132.563003] tty_port_open+0x8d/0xf0 [ 132.563523] ? uart_set_options+0x1e0/0x1e0 [ 132.564125] uart_open+0x24/0x40 [ 132.564604] tty_open+0x15c/0x630 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.