This will be reverted before freezing the KMI on this branch.
Bug: 264279944
Change-Id: Ic0229cf4e8a9462732cb0555af980747eaee6ebc
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Add hooks for vendor specific find_energy_efficient_cpu logic.
Bug: 170507310
Bug: 265387484
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I064b501017e32d4f22f8128bed8bf3a1508ab15b
(cherry picked from commit 2f108e2ec6e89609cbae32c5d13d6ad9f2e858cb)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 147a9b3d9e)
Signed-off-by: Han Lin <han.lin@mediatek.com>
This optimization allows us to re-create higher order block mappings in
the host stage2 pagetables after we teardown a guest VM. The coalescing
code is triggered on host_stage2_set_owner_locked path when we annotate
the entries in the host stage2 page-tables with an invalid entry that has
the owner set to PKVM_ID_HOST. This can also be triggered from
page_relinquish when we do page insertion in the ballooning code.
When the host reclaims ownership during guest teardown, the page table
walker drops the refcount of the counted entries and clears out
unreferenced entries (refcount == 1). Clearing out the entry installs a
zero PTE. When the host stage2 receives a data abort because there is no
mapping associated, it will try to create the largest possible block
mapping from the founded leaf entry.
With the current patch, we increase the chances of finding a leaf entry
that has level < 3 if the requested region comes from a reclaimed torned
down VM memory. This has the advantage of reducing the TLB pressure at
host stage2.
To be able to do coalescing, we modify the way we do refcounting by not
counting the following descriptor types at host stage 2:
- non-zero invalid PTEs
- any descriptor that has at least one of the reserved-high bits(58-55)
toogled
- non-default attribute mappings
- page table descriptors
The algorithm works as presented below:
Is refcount(child(pte_table)) == 1 ?
Yes -> (because we left only default mappings)
Zap the table by setting 0 in the pte_table
and put the page that holds the level 3 entries
back into the memcache
level 2
+---------+
| |
| ... |
| pte_table---+ level 3 -> we can now re-create a 2Mb mapping
| ... | +---> +---------+
| | | |
| | | |
| | |def entry|
+---------+ | |
|def entry|
| |
| ... |
+---------+
Bug: 222044487
Test: dump the host stage2 pagetables and view the mapping
Change-Id: Ib2bb3d9b5f7d2d89ae67393b59ec8bfa6c1a120c
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
During ucsi_unregister() when destroying a connector's workqueue, there
may still be pending delayed work items that haven't been scheduled yet.
Because queue_delayed_work() uses a separate timer to schedule a work
item, the destroy_workqueue() call is not aware of any pending items.
Hence when a pending item's timer expires it would then try to queue on
a dangling workqueue pointer.
Fix this by keeping track of all work items in a list, so that prior to
destroying the workqueue any pending items can be flushed. Do this by
calling mod_delayed_work() as that will cause pending items to get
queued immediately, which then allows the ensuing destroy_workqueue() to
implicitly drain all currently queued items to completion and free
themselves.
Fixes: b9aa02ca39 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking")
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Co-developed-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230110071218.26261-1-quic_jackp@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 265063961
(cherry picked from commit fac4b8633f
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Change-Id: Ia8a3e117648c503b6feba3957fd9665c4bf7a072
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Enabling CONFIG_MODULE_ALLOW_BTF_MISMATCH is an indication that BTF
mismatches are expected and module loading should proceed
anyway. Logging with pr_warn() on every one of these "benign"
mismatches creates unnecessary noise when many such modules are
loaded. Instead, handle this case with a single log warning that BTF
info may be unavailable.
Mismatches also result in calls to __btf_verifier_log() via
__btf_verifier_log_type() or btf_verifier_log_member(), adding several
additional lines of logging per mismatched module. Add checks to these
paths to skip logging for module BTF mismatches in the "allow
mismatch" case.
All existing logging behavior is preserved in the default
CONFIG_MODULE_ALLOW_BTF_MISMATCH=n case.
Signed-off-by: Connor O'Brien <connoro@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20230107025331.3240536-1-connoro@google.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Bug: 260025057
Bug: 256578296
Bug: 258989318
(cherry picked from commit 9cb61e50bfhttps://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
master)
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I2f9d19a2027610af2e825fc38fd08f56f4cd7091
These hooks will do the following works:
a) Record the number of times when target_freq being clamped
b) Record the number of times when target_freq is greater than policy->cur
c) Make corresponding optimization strategies in different hooks
d) change the value of target_freq for some scenarios
Bug: 205906618
Bug: 206896672
Bug: 265246457
Change-Id: I8eba66fd0c6d36393ca39045cf228b659834e0ae
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Signed-off-by: vincent.wang <vincent.wang@unisoc.com>
(cherry picked from commit 7e2fbdaeab)
(cherry picked from commit cf551f380a)
(cherry picked from commit d5aece2586)
Export irq_handle_exit tracepoint, so that vendor modules
can register probes for this tracepoint.
To debug irq-related issue, irq_handler_exit info must be necessary
to find whether irq exits normally or not.
And irq_handler_exit also check that irq handler is operated normally or not.
Bug: 205928005
Change-Id: I8e1eaffb7dd2f257e9c09412aad54ecca62bf019
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Export hrtimer_expire_entry/exit tracepoints, so that vendor modules
can register probes for these tracepoints.
When core stop, we need hrtimer when last hrtimer is called.
Also, rcu stall issue needs hrtimer infos.
For this reason, we have stored hrtimer infos.
Bug: 205928005
Change-Id: I739f369d3b56e09f8e9061fefdf25830e37e987e
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Export workqueue_execute_start/end tracepoints, so that vendor modules
can register probes for these tracepoints.
To debug workqueue-related issue, workqueue_execute_start/end infos must be necessary
to find whether workqueue start and exit normally or not.
And workqueue_execute_start/end also check that workqueue is operated normally or not.
Bug: 205928005
Change-Id: Ib4c8f39ff8305a1d52fbca9d06b5e792396a3a2d
Signed-off-by: Changki Kim <changki.kim@samsung.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Add new vendor hook to find new ilb cpu for power tuning.
We also set ilb initial is -1 by this patch, and we set ilb
as nr_cpu_ids by our vendor when ilb cpu not be found.
If ilb initial is 0, then when hook is not registered,
find ilb will return CPU 0.
But when hook is not registered, it should do for_each_cpu_and()
to find best ilb cpu, instead of return CPU 0 direct.
So we set ilb initial is -1, it means anyone doesn't register the hook
or the registered hook doesn't do anything, instead of ilb cpu not
be found by vendor.
Bug: 264821176
Change-Id: Idb5a8bd5862f7dd1fa30fa99aec3b42214375915
Signed-off-by: Jing-Ting Wu <Jing-Ting.Wu@mediatek.com>
Expose an API allowing to query the host stage-2 page-table to module.
Bug: 264070847
Change-Id: Ifbb2c9c8f8899778b9bf1f7df1dae81acba2af6d
Signed-off-by: Quentin Perret <qperret@google.com>
__pkvm_map_module_page() currently goes through a full host-to-hyp
donation for every module page being mapped. However, in order to allow
mapping protected pages as modules, let's make this behaviour optional.
Bug: 264070847
Change-Id: Ic3b1b68f11283c215bc8c6e1352f91bcf52a3935
Signed-off-by: Quentin Perret <qperret@google.com>
Much of the functions related to pKVM modules at EL2 are currently
guarded by the pkvm_modules_lock. This lock is only useful in case of
module hypercalls racing with __pkvm_close_module_registration().
However, the latter is by definition a privileged operation, so we can
trust that the host is not trying to exploit races to attack EL2 at this
point.
As such, let's remove the pkvm_modules_lock and re-use the existing
concept of privileged hypercalls instead. To do so, the hypercall that
limits the privileged range is moved dynamically depending on whether
pKVM modules are supported or not.
Bug: 264070847
Change-Id: I6924471339f2123ab244cdb71ffcb2a299fa75a4
Signed-off-by: Quentin Perret <qperret@google.com>
Now that the pKVM memory-management module APIs are exposed outside of
core pKVM, make sure to sanity check the input to
__pkvm_map_module_page() which expects a VA that was previously
allocated in the private range.
We can't easily check that each private VA page is used to map the
module it was allocated for, but we can at least check that all module
pages fall in the private range, which is still desirable to enforce
some degree of consitency. This is all best effort really.
Bug: 264070847
Change-Id: Ib95e464f57beaf0c32d15075938ca283fe52f720
Signed-off-by: Quentin Perret <qperret@google.com>
Some partners may need to load plug-ins in their modules, which will
require mapping the plugin code in a way that is very similar to how
pKVM maps module code. To ease this use-case, expose the pKVM module
memory-management APIs in the module_ops struct.
Bug: 264070847
Change-Id: I8b30ca50692c6860e3988b847b63ba1553c729cb
Signed-off-by: Quentin Perret <qperret@google.com>
Modules will need to convert physical addresses in EL2 linear map
addresses, so expose hyp_va to modules.
Bug: 264070847
Change-Id: I641ab3943a029072c351f5a422e2d9d2cbb240be
Signed-off-by: Quentin Perret <qperret@google.com>
As S2MPU driver was moved to an EL2 module, we need to export init
and register functions to be used from the module.
[ qperret: dropped changes to nonexistent Pixel symbol list ]
Bug: 261857213
Change-Id: I819dff0e6164051c464533d80eb68ea003b34b21
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Add functions needed by S2MPU el2 module:
-pkvm_host_donate_hyp/pkvm_hyp_donate_host: get and return SMPT from
host kernel.
-memcpy/memset: common functions used by s2mpu module.
-hyp_pa: convert hyp address to PA, to get DMA address of SMPT.
-kern_hyp_va: convert kernel address to hyp VA, used by the
module to get the VA of SMPTs allocated from the kernel.
Bug: 261857213
Change-Id: Idceccf0ac38444e7f267f50c476b99f01a613372
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
As the the s2mpu el2 driver is loaded at run time, we can't convert
its address from kernel to hyp using kern_hyp_va.
The kernel module will be responsible of sending the address of the
struct as hyp address in s2mpu hypercalls, currently the load address
of the modules is returned as the token of the module.
Although the passed arguments is the driver struct address, but the
address passed is not a kernel address, so pass it as u64 to avoid
confusing it as a kernel address.
Bug: 261857213
Change-Id: Ieb787f83d7c07ada2c8565f0e34cdc6de71aff6f
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
As S2MPU driver is used by a few devices and EL2 loadable modules
code is merged.
S2MPU pKVM driver will be moved to be an EL2 module.
This commit removes all the code and configuration for the driver.
[ qperret: fixed trivial conflict in gki_defconfig ]
Bug: 261857213
Change-Id: I53da660f8503c4bedf2fc48a90d1e8ba73329c05
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Appending -mainline should not be done on the v6.1 branch.
Since the BRANCH constant was correctly set in
e486eabf3a having
CONFIG_LOCALVERSION also set causes the bazel
//common:kernel_aarch64_test test_vmlinux_contains_scmversion
test to fail.
Bug: 264649337
Bug: 259701619
Change-Id: I9b7235bcbfdb2fafb4699dcc0e7bf809c68b608a
Signed-off-by: Peter Griffin <gpeter@google.com>
Add kasan.page_alloc.sample=10 to CONFIG_CMDLINE in gki_defconfig to make
Hardware Tag-Based (MTE) KASAN tag only one out of every 10 page_alloc
allocations with the order equal or larger than 3, which the omitted
default value for the kasan.page_alloc.sample.order parameter.
As Hardware Tag-Based KASAN is intended to be used in production, its
performance impact is crucial. As page_alloc allocations tend to be big,
tagging and checking all such allocations can introduce a significant
slowdown.
When running a local loopback test on a testing MTE-enabled device in sync
mode, enabling Hardware Tag-Based KASAN introduces a ~50% slowdown.
Setting kasan.page_alloc.sampling to a value higher than 1 allows to lower
the slowdown. The performance improvement saturates around the sampling
interval value of 10 with the default sampling page order of 3, see
b/238286329. This lowers the slowdown to ~20%. The slowdown in real
scenarios involving the network will likely be better.
Enabling page_alloc sampling has a downside: KASAN misses bad accesses to
a page_alloc allocation that has not been tagged. This lowers the value
of KASAN as a security mitigation.
However, based on measuring the number of page_alloc allocations of
different orders during boot in a test build, sampling with the default
kasan.page_alloc.sample.order value affects only ~7% of allocations. The
rest ~93% of allocations are still checked deterministically.
Bug: 238286329
Bug: 264310057
Change-Id: Idfc8600d1f7cc7af28482ff2c8e8ad5ad5948058
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
[The patch is in mm-unstable tree.]
As Hardware Tag-Based KASAN is intended to be used in production, its
performance impact is crucial. As page_alloc allocations tend to be big,
tagging and checking all such allocations can introduce a significant
slowdown.
Add two new boot parameters that allow to alleviate that slowdown:
- kasan.page_alloc.sample, which makes Hardware Tag-Based KASAN tag only
every Nth page_alloc allocation with the order configured by the second
added parameter (default: tag every such allocation).
- kasan.page_alloc.sample.order, which makes sampling enabled by the first
parameter only affect page_alloc allocations with the order equal or
greater than the specified value (default: 3, see below).
The exact performance improvement caused by using the new parameters
depends on their values and the applied workload.
The chosen default value for kasan.page_alloc.sample.order is 3, which
matches both PAGE_ALLOC_COSTLY_ORDER and SKB_FRAG_PAGE_ORDER. This is
done for two reasons:
1. PAGE_ALLOC_COSTLY_ORDER is "the order at which allocations are deemed
costly to service", which corresponds to the idea that only large and
thus costly allocations are supposed to sampled.
2. One of the workloads targeted by this patch is a benchmark that sends
a large amount of data over a local loopback connection. Most multi-page
data allocations in the networking subsystem have the order of
SKB_FRAG_PAGE_ORDER (or PAGE_ALLOC_COSTLY_ORDER).
When running a local loopback test on a testing MTE-enabled device in sync
mode, enabling Hardware Tag-Based KASAN introduces a ~50% slowdown.
Applying this patch and setting kasan.page_alloc.sampling to a value
higher than 1 allows to lower the slowdown. The performance improvement
saturates around the sampling interval value of 10 with the default
sampling page order of 3. This lowers the slowdown to ~20%. The slowdown
in real scenarios involving the network will likely be better.
Enabling page_alloc sampling has a downside: KASAN misses bad accesses to
a page_alloc allocation that has not been tagged. This lowers the value
of KASAN as a security mitigation.
However, based on measuring the number of page_alloc allocations of
different orders during boot in a test build, sampling with the default
kasan.page_alloc.sample.order value affects only ~7% of allocations. The
rest ~93% of allocations are still checked deterministically.
Link: https://lkml.kernel.org/r/129da0614123bb85ed4dd61ae30842b2dd7c903f.1671471846.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Mark Brand <markbrand@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 238286329
Bug: 264310057
Link: https://lore.kernel.org/all/129da0614123bb85ed4dd61ae30842b2dd7c903f.1671471846.git.andreyknvl@google.com
Change-Id: Icc7befe61848021c68a12034f426f1c300181ad6
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
In the updated HW-wrapped key code in the android14 kernels, HW-wrapped
keys are only allowed on a multi-block-device filesystem if they have a
compatible HW-wrapped keys implementation. While in principle this is a
good thing to check, my implementation of it, which simply checks
whether the block devices have the same crypto profiles, doesn't work
when device-mapper is being used.
To actually do that check correctly, I think we'd need to add a
HW-wrapped keys implementation name or ID to the crypto capabilities.
That being said, in Android the HW-wrapped keys implementation is a
global thing anyway. So in the interest of not overcomplicating things,
for now let's just drop these extra checks that are causing problems.
Bug: 160883801
Bug: 265180564
Fixes: 2fd53f8098 ("ANDROID: fscrypt: add support for hardware-wrapped keys")
Fixes: 139dbaa221 ("ANDROID: update "block: add basic hardware-wrapped key support" to v7")
Change-Id: Ia49d62cc2c56447fb898f19bf67df1a38af379f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a function to remap memory in the logical mapping as uncached.
This is intended to be called before calling remove_memory() in
instances where clean evictions cannot be tolerated after logical
mapping removed.
Bug: 256898253
Change-Id: I10090c7423c5dcf43d4e706ea62f86eab7b997b7
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Note that this just stops the crash, it does not correctly set the
buffer. However, since no current use case in Android requires the
buffer, this is tolerable for now.
Bug: 265206112
Test: atest android.scopedstorage.cts.host.ScopedStorageHostTest
crashes without this, passes with it
Change-Id: I25efac2b1d38fa54b9f26a3f297196fa79e5e7c3
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Note that this is specific for the non-upstreamed version
Bug: 202785178
Bug: 265206112
Test: cat /sys/fs/fuse/fuse_bpf_major_version
Change-Id: I68f9ca56778874975428839dfc1fd8f48b11bd75
Signed-off-by: Paul Lawrence <paullawrence@google.com>
This is a squash of these changes cherry-picked from common-android13-5.10
ANDROID: fuse-bpf: Make compile and pass test
ANDROID: fuse-bpf: set error_in to ENOENT in negative lookup
ANDROID: fuse-bpf: Add ability to run ranges of tests to fuse_test
ANDROID: fuse-bpf: Add test for lookup postfilter
ANDROID: fuse-bpf: readddir postfilter fixes
ANDROID: fix kernelci error in fs/fuse/dir.c
ANDROID: fuse-bpf: Fix RCU/reference issue
ANDROID: fuse-bpf: Always call revalidate for backing
ANDROID: fuse-bpf: Adjust backing handle funcs
ANDROID: fuse-bpf: Fix revalidate error path and backing handling
ANDROID: fuse-bpf: Fix use of get_fuse_inode
ANDROID: fuse: Don't use readdirplus w/ nodeid 0
ANDROID: fuse-bpf: Introduce readdirplus test case for fuse bpf
ANDROID: fuse-bpf: Make sure force_again flag is false by default
ANDROID: fuse-bpf: Make inodes with backing_fd reachable for regular FUSE fuse_iget
Revert "ANDROID: fuse-bpf: use target instead of parent inode to execute backing revalidate"
ANDROID: fuse-bpf: use target instead of parent inode to execute backing revalidate
ANDROID: fuse-bpf: Fix misuse of args.out_args
ANDROID: fuse-bpf: Fix non-fusebpf build
ANDROID: fuse-bpf: Use fuse_bpf_args in uapi
ANDROID: fuse-bpf: Fix read_iter
ANDROID: fuse-bpf: Use cache and refcount
ANDROID: fuse-bpf: Rename iocb_fuse to iocb_orig
ANDROID: fuse-bpf: Fix fixattr in rename
ANDROID: fuse-bpf: Fix readdir
ANDROID: fuse-bpf: Fix lseek return value for offset 0
ANDROID: fuse-bpf: fix read_iter and write_iter
ANDROID: fuse-bpf: fix special devices
ANDROID: fuse-bpf: support FUSE_LSEEK
ANDROID: fuse-bpf: Add support for FUSE_COPY_FILE_RANGE
ANDROID: fuse-bpf: Report errors to finalize
ANDROID: fuse-bpf: Avoid reusing uint64_t for file
ANDROID: fuse-bpf: Fix CONFIG_FUSE_BPF typo in FUSE_FSYNCDIR
ANDROID: fuse-bpf: Move fd operations to be synchronous
ANDROID: fuse-bpf: Invalidate if lower is unhashed
ANDROID: fuse-bpf: Move bpf earlier in fuse_permission
ANDROID: fuse-bpf: Update attributes on file write
ANDROID: fuse: allow mounting with no userspace daemon
ANDROID: fuse-bpf: Support FUSE_STATFS
ANDROID: fuse-bpf: Fix filldir
ANDROID: fuse-bpf: fix fuse_create_open_finalize
ANDROID: fuse: add bpf support for removexattr
ANDROID: fuse-bpf: Fix truncate
ANDROID: fuse-bpf: Support inotify
ANDROID: fuse-bpf: Make compile with CONFIG_FUSE but no CONFIG_FUSE_BPF
ANDROID: fuse-bpf: Fix perms on readdir
ANDROID: fuse: Fix umasking in backing
ANDROID: fs/fuse: Backing move returns EXDEV if TO not backed
ANDROID: bpf-fuse: Fix Setattr
ANDROID: fuse-bpf: Check if mkdir dentry setup
ANDROID: fuse-bpf: Close backing fds in fuse_dentry_revalidate
ANDROID: fuse-bpf: Close backing-fd on both paths
ANDROID: fuse-bpf: Partial fix for mmap'd files
ANDROID: fuse-bpf: Restore a missing const
ANDROID: Add fuse-bpf self tests
ANDROID: Add FUSE_BPF to gki_defconfig
ANDROID: fuse-bpf v1
ANDROID: fuse: Move functions in preparation for fuse-bpf
Bug: 202785178
Bug: 265206112
Test: test_fuse passes on linux.
On cuttlefish,
atest android.scopedstorage.cts.host.ScopedStorageHostTest
passes with fuse-bpf enabled and disabled
Change-Id: Idb099c281f9b39ff2c46fa3ebc63e508758416ee
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
pKVM modules can't rely on the usual hyp function kern_hyp_va() to
convert addr from the kernel space to the hyp's. Instead, provide
pkvm_el2_mod_va() that will do the conversion using the token provided
by pkvm_load_el2_module().
Bug: 244543039
Bug: 244373730
Change-Id: I7423b40f1107bb92cd732843c5cdbf1d45662f00
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Changes in 6.1.1
x86/vdso: Conditionally export __vdso_sgx_enter_enclave()
libbpf: Fix uninitialized warning in btf_dump_dump_type_data
PCI: mt7621: Add sentinel to quirks table
mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem
mips: ralink: mt7621: soc queries and tests as functions
mips: ralink: mt7621: do not use kzalloc too early
irqchip/ls-extirq: Fix endianness detection
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
usb: gadget: uvc: Prevent buffer overflow in setup handler
USB: serial: option: add Quectel EM05-G modem
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
staging: r8188eu: fix led register settings
igb: Initialize mailbox message for VF reset
usb: typec: ucsi: Resume in separate work
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
cifs: fix oops during encryption
KEYS: encrypted: fix key instantiation with user-provided data
Linux 6.1.1
Change-Id: I1a5f3cb051882695d6a33dc6a852415cd7a81b9a
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
timer wheel calculates the index for any timer based on the expiry
value and level granularity of the timer. Due to the level granularity
timer will not fire at the exact time instead expire at a time value
expires + granularity. This is done in the timer code when the index for
each timer is calculated based on the expiry and granularity at each
level:
expires = (expires >> LVL_SHIFT(lvl)) + 1;
For devfreq drivers the requirement is to fire the timer at the exact
time. If the timer does not expire at the exact time then it'll take
much longer to react and increase the device frequency. Devfreq driver
registers timer for 10ms expiry and due to slack in timer code the
expirty happens at 20 ms. For eg: Frame rendering time is 16ms.
If devfreq driver reacts after 20ms instead of 10ms, that's
way past a frame rendering time.
Timers with 10ms to 630ms expiry fall under level 0, to overcome the
granularity issue for level 0 with low expirty values do not add the
granularity by introducing a new calc_index vendor hook.
Bug: 178758017
Change-Id: I13cdf541e4c1bd426ce28b7a8a17cb8381eb2a92
Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com>
(cherry picked from commit 1855071010)
[quic_satyap@quicinc.com: fix minor merge conflict]
Signed-off-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Fix the calculation to determine the number of module relocs present in
the '.hyp.reloc' section to divide by the size of 'kvm_nvhe_reloc_t' (4)
instead of the size of a pointer (8).
Fixes: 3dc729d157a7 ("ANDROID: KVM: arm64: Resolve hyp module addresses using ELF sections")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: Ia7afc508039d549ae061793afa39fde9d844c069
Modules with an empty '.hyp.text' section do not contain any EL2 code
and should therefore be ignored for the purposes of hypervisor module
loading. Failing to ignore such modules will likely result in a later
loading failure due to the absence of '.hyp.reloc', which is not present
for non-hypervisor modules.
Don't bother parsing the other '.hyp.*' sections for modules with an
empty '.hyp.text' section and return early success to allow the module
to load as a normal kernel module.
Fixes: 3dc729d157a7 ("ANDROID: KVM: arm64: Resolve hyp module addresses using ELF sections")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: Idc24f95881c520b40038f77cd5af5ccc1d23624f
This reverts commit f347aa8c3d.
The '__hyprel_{start,end}' symbols are no longer used, so don't bother
generating them.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: I8e8dc5c94a9e67400e73e362e4377032328d86d4
Resolving the addresses of the hypervisor sections within a loadable
module using symbol assignment is fragile, particularly in the face of
mergeable sections (i.e. those emitted with SHF_MERGE by the compiler).
Instead, parse the ELF .hyp.* sections directly and remove the need for
global symbols in the hypervisor module linker script.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: I91d88e1a341b91ffe52ffc770dddc9b46ccb3aa4
Add vendorhook to allow mmaping more memory than a DMA-BUF holds. The
implementor of the vmap callback for the DMA-BUF is responsible for
ensuring that all pages are backed by memory. The hook takes as input
a DMA-BUF to allow the VMA bounds check to be done on a case-by-case
basis for DMA-BUFs.
Note that if the override is allowed to go through for a given
DMA-BUF, then it can be the case that the size of this mmaped DMA-BUF
is reported incorrectly when looking at /proc/pid/maps for the owning
process.
Bug: 234753494
Change-Id: Iba8cc8adfd2290e4dc7ef04fce5d6a80ac92e0b3
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
Add a sample program that supports various tests that the FIPS
certification lab is required to do on fips140.ko. To do its work it
uses AF_ALG, as well as the /dev/fips140 device node provided by a build
of fips140.ko with CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING enabled.
Original commits:
android12-5.10:
109f31ac23 ("ANDROID: fips140: add userspace interface for evaluation testing")
a481d43521 ("ANDROID: fips140: refactor and rename fips140_lab_test")
3a624c9ccd ("ANDROID: fips140: add show_invalid_inputs command to fips140_lab_util")
fe60669d03 ("ANDROID: fips140: add dump_jitterentropy command to fips140_lab_util")
Bug: 153614920
Bug: 188620248
Change-Id: Ide1875f39d439c3955d03a5f41160382544d47bd
Signed-off-by: Eric Biggers <ebiggers@google.com>
To meet FIPS 140 requirements, add support for building a kernel module
"fips140.ko" that contains various cryptographic algorithms built from
existing kernel source files. At load time, the module checks its own
integrity and self-tests its algorithms, then registers the algorithms
with the crypto API to supersede the original algorithms provided by the
kernel itself.
[ebiggers: this commit originated from "ANDROID: crypto: fips140 -
perform load time integrity check", but I've folded many later commits
into it to make forward porting easier. See below]
Original commits:
android12-5.10:
6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
868be244bb ("ANDROID: inject correct HMAC digest into fips140.ko at build time")
091338cb39 ("ANDROID: fips140: add missing static keyword to fips140_init()")
c799c6644b ("ANDROID: fips140: adjust some log messages")
92de53472e ("ANDROID: fips140: log already-live algorithms")
0af06624ea ("ANDROID: fips140: check for errors from initcalls")
634445a640 ("ANDROID: fips140: fix deadlock in unregister_existing_fips140_algos()")
e886dd4c33 ("ANDROID: fips140: unregister existing DRBG algorithms")
b7397e89db ("ANDROID: fips140: add power-up cryptographic self-tests")
50661975be ("ANDROID: fips140: add/update module help text")
b397a0387c ("ANDROID: fips140: test all implementations")
17ccefe140 ("ANDROID: fips140: use full 16-byte IV")
1be58af077 ("ANDROID: fips140: remove non-prediction-resistant DRBG test")
2b5843ae2d ("ANDROID: fips140: add AES-CBC-CTS")
2ee56aad31 ("ANDROID: fips140: add AES-CMAC")
960ebb2b56 ("ANDROID: fips140: add jitterentropy to fips140 module")
e5b14396f9 ("ANDROID: fips140: take into account AES-GCM not being approvable")
52b70d491b ("ANDROID: fips140: use FIPS140_CFLAGS when compiling fips140-selftests.c")
6b995f5a54 ("ANDROID: fips140: preserve RELA sections without relying on the module loader")
e45108ecff ("ANDROID: fips140: block crypto operations until tests complete")
ecf9341134 ("ANDROID: fips140: remove in-place updating of live algorithms")
482b0323cf ("ANDROID: fips140: zeroize temporary values from integrity check")
64d769e53f ("ANDROID: fips140: add service indicators")
8d7f609cda ("ANDROID: fips140: add name and version, and a function to retrieve them")
6b7c37f6c4 ("ANDROID: fips140: use UTS_RELEASE as FIPS version")
903e97a0ca ("ANDROID: fips140: refactor evaluation testing support")
97fb2104fe ("ANDROID: fips140: add support for injecting integrity error")
109f31ac23 ("ANDROID: fips140: add userspace interface for evaluation testing")
android14-5.15:
84572a0c79 ("ANDROID: fips140: split dump-section+add-section into 2 ops")
b0f8873811 ("ANDROID: kleaf: convert fips140 to kleaf")
2535deae80 ("ANDROID: GKI: Source GKI_BUILD_CONFIG_FRAGMENT after setting all variables")
685a2ade28 ("ANDROID: fips140: add crypto_memneq() back to the module")
320dfca58a ("ANDROID: fips140: fix in-tree builds")
d4966a8203 ("ANDROID: fips140: remove CONFIG_CRYPTO_FIPS140 option")
6da26b8750 ("ANDROID: fips140: require 'm' to enable CRYPTO_FIPS140_MOD")
bfcfcce380 ("ANDROID: fips140: unapply ABS32 relocations generated by KCFI")
63f46b45dd ("ANDROID: fips140: eliminate crypto-fips.a build step")
ae4ca7a09b ("ANDROID: fips140: allow building without LTO")
Bug: 153614920
Bug: 188620248
Test: tested that the module builds and can be loaded on raven.
Change-Id: I3fde49dbc3d16b149b072a27ba5b4c6219015c94
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
may_use_simd() should only be called by code that may use FP/SIMD when
it is available, and so checking whether the system supports FP/SIMD in
the first place should be redundant - the caller in question (e.g., a
SIMD crypto algorithm) should never be initialized in the first place.
Checking the system capability involves jump labels and therefore code
patching, which interferes with our ability to perform an integrity
check on some of the crypto code. So let's get rid of the capability
check altogether.
Bug: 153614920
Bug: 188620248
Change-Id: Ia8df624f4648cc980a12a44eeb82e8f186d5f961
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
The arm64 LSE atomics implementation uses both alternatives patching and
jump label patching, both of which need to be selectively disabled when
building the FIPS140 module, or the hashing of the .text section no
longer works.
We already disable jump labels in generic code, but this uncovers a
rather nasty circular include dependency, as the jump label fallback
code uses atomics, which are provided by the LSE code if enabled.
So let's disable LSE as well when building the FIPS140 module: this does
not have any impact on the code, as no code patching goes on in this
module anyway, but it avoids #include hell.
Bug: 153614920
Bug: 188620248
Change-Id: Ia3d823fa3a309777f0c955d619ae8b139dc74061
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
The FIPS140 crypto module takes a HMAC digest of its own .text and
.rodata section in its module_init() hook. This digest is compared to a
digest taken at build time, which means that we need to take some extra
care to ensure that the build time and runtime versions line up.
One thing we cannot tolerate in this case is alternatives patching. In
the general case, we cannot simply ignore alternatives, but fortunately,
there is only a small subset that actually gets instantiated in the
FIPS140 module, and all of these can be ignored if we are willing to
accept that the FIPS140 module does not support VHE hardware, and does
not work when running with pseudo-NMI support enabled. None of this is
important for the use case targeted by the FIPS140 module, so this is
something we should be able to live with.
Bug: 153614920
Bug: 188620248
Change-Id: Ie6666e01d5524a3c33aa451609bab2f29b612f8c
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
The fips140 module doesn't support jump labels, as they would invalidate
the hash of the .text section. So when building the module, switch to
the generic implementation that does not rely on arch-specific code
patching support.
This fixes a failure in check_fips140_module_hmac() caused by the module
containing a call to crypto_alg_put(), which is an inline function that
calls refcount_dec_and_test(), which on arm64 uses a jump label.
Note that the optimized definition of struct static_key is retained, to
ensure ABI compatibility across the FIPS140 module boundary. To ensure
that static keys and their associated jump labels remain in a consistent
state, the fips140 module will not be able to manipulate static keys,
but only to check their state.
Bug: 153614920
Bug: 188620248
Change-Id: Ie834bbf2eed5d09bfae7f387b711a934bedf390d
Signed-off-by: Eric Biggers <ebiggers@google.com>
[ardb: disable jump labels in generic code not in arm64 arch code]
Signed-off-by: Ard Biesheuvel <ardb@google.com>
In fips140.ko, enable the behavior that the upstream fips_enabled flag
controls, such as the XTS weak key check which apparently is required.
Note that some of this behavior, such as the DRBG continuity check, is
allegedly not required. But to ensure we don't miss anything that was
already handled upstream, it seems best to define fips_enabled to 1. We
can still disable anything that turns out to be problematic.
Bug: 153614920
Bug: 188620248
Change-Id: Idcded9e69e7d7cdf7f2937009af209857b0c08e2
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add vendor hooks that will allow the FIPS140 kernel module to override
the implementations of the AES library routines. The FIPS 140 versions
are identical to the normal ones, but their code and rodata will have
been integrity checked at module load time.
Original commits:
android12-5.10:
9c556792b7 ("ANDROID: crypto: lib/aes - add vendor hooks for AES library routines")
android14-5.15:
d4966a8203 ("ANDROID: fips140: remove CONFIG_CRYPTO_FIPS140 option")
Bug: 153614920
Bug: 188620248
Change-Id: I5711fc42eced903565fd3c8d41ca7cdd82641148
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a vendor hook that will allow the FIPS140 kernel module to override
the implementation of the sha256() library routine. The FIPS 140 version
is identical to the normal one, but its code and rodata will have been
integrity checked at module load time.
Original commits:
android12-5.10:
1e351b98e7c7 ("ANDROID: crypto: lib/sha256 - add vendor hook for sha256() routine")
android14-5.15:
0ef21e1c1a ("ANDROID: vendor_hooks: Reduce pointless modversions CRC churn")
d4966a8203 ("ANDROID: fips140: remove CONFIG_CRYPTO_FIPS140 option")
Bug: 153614920
Bug: 188620248
Change-Id: I8ccc4f0cc8206af39fa922134b438dacac2a614a
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
To meet FIPS requirements, fips140.ko must check its own integrity at
load time. This requires that it know where its .text and .rodata
sections are. To allow this, make the module linker script support
defining symbols that enclose these sections.
In addition, support creating an .initcalls section, so that fips140.ko
can include code from what would normally be multiple modules by
compiling it as "built-in" code.
[ebiggers: Separated this out from the original commit
"ANDROID: crypto: fips140 - perform load time integrity check" and
folded in later changes to the script. See below.]
Original commits:
android12-5.10:
6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
e8d56bd78b ("ANDROID: module: apply special LTO treatment to .text even if CFI is disabled")
109f31ac23 ("ANDROID: fips140: add userspace interface for evaluation testing")
android14-5.15:
57be8919bf ("ANDROID: fips140: consolidate linker script changes into module.lds.S")
d4966a8203 ("ANDROID: fips140: remove CONFIG_CRYPTO_FIPS140 option")
6da26b8750 ("ANDROID: fips140: require 'm' to enable CRYPTO_FIPS140_MOD")
ae4ca7a09b ("ANDROID: fips140: allow building without LTO")
Bug: 153614920
Bug: 188620248
Change-Id: I22209ff4e6444f9115eca6909bcb653fd5d14aec
Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
On older kernel branches, the inclusion of kernel headers in the
vendor hooks source file (drivers/android/vendor_hooks.c) was
guarded with `#ifndef __GENKSYMS__` since the headers were
added to the source file after those branches were KMI frozen.
If the header inclusions were not guarded by `#ifndef __GENKSYMS__`
then the existing CRC values of the symbols in the KMI would have
been impacted, resulting in a KMI break.
Given that this problem does not exist on android14-6.1, remove
the usage of `#ifndef __GENKSYMS__` in drivers/android/vendor_hooks.c.
Bug: 264895944
Change-Id: Iaf051ec4ab00a8239b8e1bc74034717e8bbdc588
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Add a vendor hook that allows overriding the default alloc_iova()
algorithm.
The vendor hook can use the iovad->android_vendor_data1 field, initialized
in the previous patch, to determine whether to use the best-fit algorithm
to allocate iova for this device. If an IOVA was successfully allocated,
the vendor hook returns 0. Otherwise it returns non-zero and we fallback
to the default, first-fit algorithm.
On some 32-bit devices, using a best-fit algorithm reduces chances of the
allocation failure due to fragmentation.
We submitted patches (listed in Links below) with two different approaches
to the community but they were not accepted in part, because we are not
able to reproduce the problem with upstream-only code.
Links:
[1] Use a DT property:
https://lore.kernel.org/lkml/20221213163506.GA2011062-robh@kernel.org/
[2] Add an API function to be called by user drivers:
https://lore.kernel.org/lkml/20200217080339.GC10342@infradead.org/
Bug: 263499813
Bug: 190519428
Bug: 149544392
Change-Id: I8e948a08e79089d3fb7356eeb7f85b58784688f2
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
