Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
kernel/power/suspend.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie7497d13d654d3a430082291090b626b1bc638c2
The 5.16-rc1 kernel has changed the default to disable eBPF unprivileged
programs to run because of Intel's broken hardware which allows for
speculation leaks to happen very easily on those platforms. This is not
an issue on the majority of Android systems, and the Android networking
functionality relies on this feature, so specifically disable the
configuration option so that things continue to work properly.
Disabling a disable configuration option, ugh...
Fixes: 8a03e56b25 ("bpf: Disallow unprivileged bpf by default")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifd055add42ec1e8360c3d7823ae12567513dba19
While overriding sugov behavior, it is also necessary to know the
runqueue on which the task is going to be enqueued.
Bug: 171598214
Change-Id: I1491a2be34a6e615c5d4bc68e095647744870233
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
Steps on the way to 5.16-rc1
Resolves merge conflicts in:
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6f34ccdd38594c59146fd6b7cd25904ab83bb063
br_switchdev_mdb_notify() is conditionally compiled only when
CONFIG_NET_SWITCHDEV=y and CONFIG_BRIDGE_IGMP_SNOOPING=y. It is called
from br_mdb.c, which is conditionally compiled only when
CONFIG_BRIDGE_IGMP_SNOOPING=y.
The shim definition of br_switchdev_mdb_notify() is therefore needed for
the case where CONFIG_NET_SWITCHDEV=n, however we mistakenly put it
there for the case where CONFIG_BRIDGE_IGMP_SNOOPING=n. This results in
build failures when CONFIG_BRIDGE_IGMP_SNOOPING=y and
CONFIG_NET_SWITCHDEV=n.
To fix this, put the shim definition right next to
br_switchdev_fdb_notify(), which is properly guarded by NET_SWITCHDEV=n.
Since this is called only from br_mdb.c, we need not take any extra
safety precautions, when NET_SWITCHDEV=n and BRIDGE_IGMP_SNOOPING=n,
this shim definition will be absent but nobody will be needing it.
Fixes: 9776457c78 ("net: bridge: mdb: move all switchdev logic to br_switchdev.c")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20211029223606.3450523-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit ae0393500e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic0e3c6290af073ed8b500611fe6ae3e6b5e2cce6
Steps on the way to 5.16-rc1
Resolves conflicts in:
include/net/sock.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I65e908f7cb0a0588b4eb37afb0ce221981d0aab5
Steps on the way to 5.16-rc1
Resolves merge conflicts with:
tools/testing/selftests/net/ioam6.sh
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2c7f5ee7cb7c5df2b757d7284e23eb5bd9851851
Building an allmodconfig kernel arm64 kernel, the following build error
shows up:
In file included from drivers/crypto/marvell/octeontx2/cn10k_cpt.c:4:
include/linux/soc/marvell/octeontx2/asm.h:38:15: error: unknown type name 'u64'
38 | static inline u64 otx2_atomic64_fetch_add(u64 incr, u64 *ptr)
| ^~~
Include linux/types.h in asm.h so the compiler knows what the type
'u64' are.
Fixes: af3826db74 ("octeontx2-pf: Use hardware register for CQE count")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Link: https://lore.kernel.org/r/20211013135743.3826594-1-anders.roxell@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 6312d52838)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I94a5f0cd94166d3b2d111aea52a7114b06500086
Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
drivers/net/ethernet/intel/ice/ice_devlink.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I188502a1e6b84b61582bf3f5539785f8f2e7864f
This reverts commit 6b7933539f.
It causes lots of merge conflicts with upstream changes that come into
the tree in 5.16-rc1, so revert it for now. If this is really still
needed, it can come back later, ideally it should go upstream first.
Bug: 202075496
Cc: Yifan Hong <elsk@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I994ce12885e06bb984c1b8cbe3d9c5663f77bb51
Commit a52f8a59ae ("fortify: Explicitly disable Clang support")
dropped fortify support for clang compilers until the compiler is fixed
up. This requires us to also drop it from the gki configurations as it
is not able to be selected anymore.
Fixes: a52f8a59ae ("fortify: Explicitly disable Clang support")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iad106506847e3f88c1129e8c61f58f68412f7cae
Commit c597bfddc9 ("sched: Provide Kconfig support for default dynamic
preempt mode") changed the dependancies for CONFIG_PREEMPT, now
CONFIG_PREEMPT_BEHAVIOR needs to be set, so fix up the GKI config files
to properly do this.
Fixes: c597bfddc9 ("sched: Provide Kconfig support for default dynamic preempt mode")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9b2e80b93985159a1925af3af8c221b556577f3d
Steps on the way to 5.16-rc1.
Resolves merge conflicts in:
kernel/irq_work.c
kernel/sched/core.c
kernel/sched/fair.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4b144ffba858a38a417e9d71d76c23d015b7aa9b
clang is throwing up when it hits the BUILD_BUG_ON() macro at the
moment, so remove it from arch_time.h for arm64 to fix the build at this
point in time.
Fixes: a1cb80290f ("Merge 57a315cd71 ("Merge tag 'timers-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") into android-mainline")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Marc Zyngier <mzyngier@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0ccd2fa80b3f9fea92464ba40cd3ca6ad013a5d1
`__compiletime_assert` declares a fake `extern` function
which appears (to the compiler) to be called when the test fails.
Therefore, compilers may emit possibly-uninitialized warnings
in some cases, even if it will be an error anyway (for compilers
supporting the `error` attribute, e.g. GCC and Clang >= 14)
or a link failure (for those that do not, e.g. Clang < 14).
Annotating the fake function as `__noreturn` gives them
the information they need to avoid the warning,
e.g. see https://godbolt.org/z/x1v69jjYY.
Link: https://lore.kernel.org/llvm/202110100514.3h9CI4s0-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Change-Id: I6aaf5325bc7821cafda8fea501e8e304750ad84a
Fixes: a1cb80290f ("Merge 57a315cd71 ("Merge tag 'timers-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") into android-mainline")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add support for hardware-wrapped keys to fscrypt. Hardware-wrapped keys
are inline encryption keys which are only present in kernel memory in
ephemerally-wrapped form, and which can only be unwrapped by dedicated
hardware. Such keys are protected from certain attacks, such as cold
boot attacks. For more information, see the "Hardware-wrapped keys"
section of Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys in fscrypt, we allow the fscrypt master
keys to be hardware-wrapped, and we allow encryption policies to be
flagged as needing a hardware-wrapped key. File contents encryption is
done by passing the wrapped key to the inline encryption hardware via
blk-crypto. Other fscrypt operations such as filenames encryption
continue to be done by the kernel, using the "software secret" which the
hardware derives.
Note that this feature doesn't require any filesystem-specific changes.
However it does depend on inline encryption support, and thus currently
it is only applicable to ext4 and f2fs, not to ubifs or CephFS.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867364, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1200864.
This is based on a version of this patch that I've proposed upstream
(https://lore.kernel.org/r/20211021181608.54127-4-ebiggers@kernel.org),
but by necessity it preserves the existing UAPI and on-disk format which
Android expects. I also dropped the changes to the documentation file.
Bug: 160883801
Change-Id: If4bb83f1188a5863184717c04cb8a064dc4ea168
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update the device-mapper core to support exposing the inline crypto
support of wrapped keys through the device-mapper device.
derive_sw_secret in keyslot manager is used to derive the software
secret from the given wrapped keyblob using the underlying blk device.
Given that the sw_secret is the same for a given wrapped keyblob the
call exits when the first underlying blk-device suceeds.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867366, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1229460.
Bug: 147209885
Bug: 160883266
Bug: 160883801
Test: Validated FBE with wrappedkey_v0 when /data is mounted on a
dm device.
Change-Id: Id30d00afdbd3114e089887db1493ffd41e833e21
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware supports
protecting the keys in hardware without software having access to or the
ability to set the plaintext keys. Instead, software only sees "wrapped
keys", which may differ on every boot. The keys can be initially
generated either by software (in which case they need to be imported to
hardware to be wrapped), or directly by the hardware.
Add support for this type of hardware by allowing keys to be flagged as
hardware-wrapped. When used, dm-default-key will pass the wrapped key
to the inline encryption hardware to encryption metadata. The hardware
will internally unwrap the key and derive the metadata encryption key.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867365, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1224286.
Bug: 147209885
Bug: 160883801
Bug: 160883266
Bug: 160885805
Test: Validate metadata encryption & FBE with wrapped keys.
Change-Id: I38393727bf71e5d20b3c3ac9d2af62a1864a0a82
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the plaintext keys in kernel memory, without restricting
the number of keys that can be used. Such keys can be initially
generated either by software (in which case they must be imported to
hardware to be wrapped) or directly by the hardware. There is also a
mechanism to derive a "software secret" for cryptographic tasks that
can't be handled by inline encryption.
To support this hardware, allow struct blk_crypto_key to represent a
hardware-wrapped key as an alternative to a standard key, and make
drivers set flags in struct blk_crypto_profile to indicate which types
of keys they support. Also add the derive_sw_secret() low-level
operation, which drivers supporting wrapped keys must implement.
For more information, see the detailed documentation which this patch
adds to Documentation/block/inline-encryption.rst.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867367, and
which originated from several ANDROID patches that were consolidated by
https://android-review.googlesource.com/c/kernel/common-patches/+/1350782.
This version of the patch matches the patch in the below "Link:" tag
that was sent upstream as an RFC. However, due to its history as
ANDROID, it remains tagged as ANDROID rather than FROMLIST.
Bug: 160883801
Link: https://lore.kernel.org/r/20211021181608.54127-2-ebiggers@kernel.org
Change-Id: I4d18c261c279d606457b33374234c0a037e1d45a
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE which tells ufshcd-core that the
host controller supports inline encryption, but it needs to initialize
the crypto capabilities in a nonstandard way and/or it needs to override
blk_crypto_ll_ops. If enabled, the standard code won't initialize the
blk_crypto_profile; ufs_hba_variant_ops::init() must do it instead.
Note that it is permitted that the blk_crypto_profile has no keyslots.
This is needed for FMP support, as well as for wrapped key support.
This is a reworked version of a patch which was temporarily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867368, and
which originated from several ANDROID patches that were consolidated by
https://android-review.googlesource.com/c/kernel/common-patches/+/1508579.
Bug: 162257402
Bug: 160883801
Change-Id: I556a68cd2d11bd5a7353fefdc31920475a5e7425
Signed-off-by: Eric Biggers <ebiggers@google.com>
TEO governor was implemented in android12-5.10, however CONFIG_CPU_IDLE_GOV_TEO
was not enabled in gki_defconfig and vendor can not select TEO governor.
This commit enable TEO and MENU governors in gki_defconfig, and vendors can
select the governor they wanted, e.g. in rc file:
write /sys/devices/system/cpu/cpuidle/current_governor "teo"
Besides, MENU governor's rating is 20, and higher than TEO governor,
so MENU governor is still the default governor if vendors not select the governor manually.
Bug: 185762657
Change-Id: I87be7c4d119f17901b921f22dd7df8b61ac539af
Signed-off-by: rogercl.yang <rogercl.yang@mediatek.com>
(cherry picked from commit ea527a52d1)
Histogram triggers (already enabled for arm64) will be used
to throttle frequent trace events on Android.
Bug: 146055070
Bug: 145972256
Change-Id: Ia186a79867866e5b4ed37f2cc14be194505f3fba
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
