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>
Add a vendor hook that allows initializing the iovad->android_vendor_data1
field to indicate whether to use the first-fit or best-fit algorithm for
this device when allocating IOVAs.
Bug: 263499813
Bug: 190519428
Bug: 149544392
Change-Id: I0c894b32416a459d7a58aa076770daedcce67cc3
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
The alloc_iova() implementation uses a first-fit algorithm when allocating
an IOVA. On some devices, specially with 32-bit IOVA space, this can lead
to fragmentation and result in larger IOVA allocations failing. For such
devices, the best-fit algorithm works better.
Add a vendor field to iova_domain that can be used to indicate that the
best-fit algorithm should be used when allocating IOVAs for this device
(iova_domain).
Bug: 263499813
Bug: 190519428
Bug: 149544392
Change-Id: Ie7dec70ee158075804209f83ae68e5ae0cc20775
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
Currently, only HS descriptors will be updated with endpoint address
during binding process. According to current max_speed in configfs,
this patch will also update SS/SSP descriptors with endpoint address.
Bug: 162562782
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: I67983ef47df7ac567ec1d3af80921c39c98a545d
(cherry picked from commit 41fe558317)
(cherry picked from commit ba3ec687b7)
When running the clean target, kbuild is supposed to remove dtbs and
dtbos. However, kbuild only searches for those devicetree build
artifacts in the directory that the kernel binaries or kernel modules
are output to. This is not sufficient in cases where an external
devicetree is used, so include the external devicetree path when
searching for dtb and dtbo build artifacts.
Bug: 264602319
Fixes: 3d42cc9e75 ("ANDROID: kbuild: add support for compiling external device trees")
Change-Id: I45fdfdef09c3d57401d98e5db731273147d7d265
[isaacmanjarres: resolved trivial merge conflict]
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
This reverts commit 1af7ed3212.
Bug: 264333547
Test: /data/local/tmp/sebastianene/tests/test_host_app
Change-Id: Id88b705dd725cc8720913fd2909030c2f2fb597f
Signed-off-by: Sebastian Ene <sebastianene@google.com>
The hypervisor memory pool is sized to allow mapping up to 1GiB of data
in the 'private' range of the hypervisor. However, this is currently
not enforced in any way, which might become a problem as private range
mappings are used more and more (e.g. from pKVM modules).
Enforce the 1GiB limit at allocation time, and while at it, rename
__io_map_base to __private_range_base for consistency.
Bug: 244543039
Change-Id: I32c9145ba331309b49428ff461a41c94ea0c1512
Signed-off-by: Quentin Perret <qperret@google.com>
Parse the devicetree during pKVM init to find nodes with the
"pkvm,protected-region" compatible string. These nodes specify a
physical address range in reg that must alway be mapped as invalid in
the host stage-2 page table when running under pKVM.
Example DT:
pkvm_prot_reg: pkvm_prot_reg@80000000 {
compatible = "pkvm,protected-region";
reg = <0x00 0x80000000 0x00 0x200000>;
};
Bug: 244543039
Bug: 244373730
Change-Id: I102cd16c91d96e5283cdd1a4fa58836cc4834eac
Signed-off-by: Quentin Perret <qperret@google.com>
The pKVM memory pool is currently sized to allow page-granularity
mapping in the host stage-2 page-table of all the memory as well as up
to 1GiB of MMIO range. Indeed, pKVM currently assumes that MMIO regions
are completely and solely owned by the host for the entire lifetime of
the system. As such, the pages used to map MMIO regions can always be
recycled to allow forward progress if the memory pool ran out of
pages -- pKVM can unmap MMIO ranges at stage-2 without fearing to loose
important information about the state of the underlying page, and those
mappings can always be reconstructed later.
In order to allow transitioning the ownership of non-memory regions,
introduce a concept of pkvm 'moveable' regions, which represents regions
of the physical address space which can be 'moved' from an ownership
perspective. These moveable regions are used to size the hyp memory
pool. In a first step, the list of moveable regions is equal to the
memblock list, but it will be extended in subsequent changes.
No functional changes intended.
Bug: 244543039
Bug: 244373730
Change-Id: I7f451924b1eed9579868e6ff8c7adc7b4a5a0ae1
Signed-off-by: Quentin Perret <qperret@google.com>
The host_get_page_state() logic has currently a baked in assumption that
it will only be used on memory, and checks against the default memory
permssions to flag pages as having a RESTRICTED_PROT state.
Add support for correctly flagging non-memory pages to prepare the
ground for future patches.
Bug: 244543039
Bug: 244373730
Change-Id: Idaaef96cb98c147c8b793059438064cf770af525
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM uses different default permissions for memory and non-memory
regions of the PA space. To avoid scattering this logic around,
introduce a default_host_prot() helper function.
Non functional changes intended.
Bug: 244543039
Bug: 244373730
Change-Id: I36cdbb26a2cb0d54b5641f945f6ede4ffe371045
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM modules may need to be notified in case of unexpected same-level
EL2 exceptions, which result in a hyp panic. To do so, introduce a new
notifier on the hyp_panic path.
Bug: 244373730
Change-Id: I144609a933d648ddf2aebcd950e64d6035bf8be3
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM modules may need to temporarily map large-ish physically contiguous
regions of memory when bootstrapping themselves. In order to support
this use-case, introduce two new APIs in the module_ops struct allowing
to map and unmap pages in pKVM's linear map range. Since pKVM's page
ownership infrastructure relies on linear map PTEs, this needs to be
done with special care. To avoid any problem, let's count the number of
pages mapped by modules and unsure they have been unmapped before
reaching the point of deprivilege.
Bug: 244373730
Change-Id: I4aecb93f5c9ba08d9f830d1f0976704688b98509
Signed-off-by: Quentin Perret <qperret@google.com>
It comes with the commit efbb82d3b0db ("ANDROID: Add a vendor hook
that allow a module to modify the wake flag"). A vendor who want to
hook sock_def_readable can set this vendor-specific wake flag.
sock_def_readable ->
(vendor hook will call __wake_up_sync_key with a custom mode) ->
__wake_up_sync_key ->
(vendor hook changes wake_flags per the custom mode) ->
__wake_up_common -> default_wake_function
It is an Android-specific since it works with a vendor hook.
Bug: 189858948
Bug: 226256614
Bug: 263838089
Signed-off-by: Namkyu Kim <namkyu78.kim@samsung.com>
Change-Id: Idc23c1c47f7d83b298c0b2560859f1ce2761fd85
(cherry picked from commit 4c1097df5d)
(cherry picked from commit 87b89ce83b)
Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
android_vh_do_wake_up_sync:
To modify the mode value of __wake_up_sync_key
android_vh_set_wake_flags:
To modify the wake flag from a module
Bug: 181743516
Bug: 263838089
Signed-off-by: Namkyu Kim <namkyu78.kim@samsung.com>
Change-Id: I972e2469c3f139373d21f1e8c85974763388a693
(cherry picked from commit 97368fc2dc)
(cherry picked from commit 0d0f0c5020)
[Dongseok Yi: Moved into kernel/sched/vendor_hooks.c per commit
5f657b04f4 ("ANDROID: subsystem-specific vendor_hooks.c for
sched")]
Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
Add the hook for the waiter list of futex to allow
vendor perform wait queue enhancement
Bug: 264007752
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Signed-off-by: Guanwun Chen <guan-wun.chen@mediatek.com>
Change-Id: I68218b89c35b23aa5529099bb0bbbd031bdeafef
Add the hook to apply vendor's performance tune for owner
of rwsem.
Add the hook for the waiter list of rwsem to allow
vendor perform waiting queue enhancement
ANDROID_VENDOR_DATA added to rw_semaphore
Bug: 264007752
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Signed-off-by: Guanwun Chen <guan-wun.chen@mediatek.com>
Change-Id: I007a5e26f3db2adaeaf4e5ccea414ce7abfa83b8
The new sysctl sched_pelt_multiplier allows a user to set a clock
multiplier to x2 or x4 (x1 being the default). This clock multiplier
artificially speeds up PELT ramp up/down similarly to use a faster
half-life than the default 32ms.
- x1: 32ms half-life
- x2: 16ms half-life
- x4: 8ms half-life
Internally, a new clock is created: rq->clock_task_mult. It sits in the
clock hierarchy between rq->clock_task and rq->clock_pelt.
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Bug: 263742061
Link: https://lore.kernel.org/lkml/20220829055450.1703092-2-dietmar.eggemann@arm.com
Change-Id: Id379ff3cf07733ae63a854bc1e5af64426576788
Signed-off-by: Jing-Ting Wu <Jing-Ting.Wu@mediatek.com>
* aosp/upstream-f2fs-stable-linux-6.1.y:
f2fs: let's avoid panic if extent_tree is not created
f2fs: should use a temp extent_info for lookup
f2fs: don't mix to use union values in extent_info
f2fs: initialize extent_cache parameter
f2fs: fix to avoid NULL pointer dereference in f2fs_issue_flush()
fscrypt: add additional documentation for SM4 support
fscrypt: remove unused Speck definitions
fscrypt: Add SM4 XTS/CTS symmetric algorithm support
blk-crypto: Add support for SM4-XTS blk crypto mode
blk-crypto: pass a gendisk to blk_crypto_sysfs_{,un}register
fscrypt: add comment for fscrypt_valid_enc_modes_v1()
blk-crypto: Add a missing include directive
blk-crypto: move internal only declarations to blk-crypto-internal.h
blk-crypto: add a blk_crypto_config_supported_natively helper
blk-crypto: don't use struct request_queue for public interfaces
fscrypt: pass super_block to fscrypt_put_master_key_activeref()
Bug: 256243893
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I367525066c097ee6ebeb4cf59d7a1c4b23b65c8a
Export clocksource_mmio_init and clocksource_mmio_readl_up
to support building clocksource driver as module,
such as timer-mediatek.c.
Bug: 161675989
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Change-Id: I7df2f2ac62f2322c1d32686907cb0bd87639f6fc
(cherry picked from commit bd213d9a67)
The hardware-wrapped key support in this branch is based on my patch
"[RFC PATCH v3 3/3] fscrypt: add support for hardware-wrapped keys"
(https://lore.kernel.org/r/20211021181608.54127-4-ebiggers@kernel.org)
I've since made several updates to that patch and it is now at v7.
This commit brings in the updates from v3 to v7, to the extent possible
while retaining compatibility with the UAPI and on-disk format used for
this feature in Android. This mainly includes some improved log
messages, and compatibility with the blk-crypto updates.
Bug: 160883801
Link: https://lore.kernel.org/all/20221216203636.81491-5-ebiggers@kernel.org
Change-Id: I1c43ca55ec7e95dd06f8f7944100ffd14771d3a7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update this code to be compatible with the updated version of
"block: add basic hardware-wrapped key support".
Bug: 160883801
Change-Id: Ic6991ad163035870ace3cd468f53b21a824c5359
Signed-off-by: Eric Biggers <ebiggers@google.com>
The hardware-wrapped key support in this branch is based on my patch
"[RFC PATCH v3 1/3] block: add basic hardware-wrapped key support"
(https://lore.kernel.org/all/20211021181608.54127-2-ebiggers@kernel.org).
I've since made several updates to that patch and it is now at v7.
This commit brings in the updates from v3 to v7. The main change is
making blk_crypto_derive_sw_secret() operate on a struct block_device,
and adding blk_crypto_hw_wrapped_keys_compatible(). This aligns with
changes upstream in v6.1 and v6.2 that removed block-layer internal
structures from the API that blk-crypto exposes to upper layers.
There's also a slight change in prototype for ->derive_sw_secret, so a
couple out-of-tree drivers will need to be updated, but people
maintaining out-of-tree drivers know what they are dealing with anyway.
Bug: 160883801
Link: https://lore.kernel.org/r/20221216203636.81491-2-ebiggers@kernel.org
Change-Id: I0f285c11c2764064cd4a9d6eac0089099a9601ed
Signed-off-by: Eric Biggers <ebiggers@google.com>
The prototypes of blk_crypto_evict_key() and
blk_crypto_start_using_key() changed, so update the callers in
dm-default-key which is not upstream.
Bug: 160885805
Change-Id: Ie39a298d8aca77c042f11bbfa25fd9bf50593c52
Signed-off-by: Eric Biggers <ebiggers@google.com>
Allow the compiler to verify consistency of function declarations and
function definitions. This patch fixes the following sparse errors:
block/blk-crypto-profile.c:241:14: error: no previous prototype for ‘blk_crypto_get_keyslot’ [-Werror=missing-prototypes]
241 | blk_status_t blk_crypto_get_keyslot(struct blk_crypto_profile *profile,
| ^~~~~~~~~~~~~~~~~~~~~~
block/blk-crypto-profile.c:318:6: error: no previous prototype for ‘blk_crypto_put_keyslot’ [-Werror=missing-prototypes]
318 | void blk_crypto_put_keyslot(struct blk_crypto_keyslot *slot)
| ^~~~~~~~~~~~~~~~~~~~~~
block/blk-crypto-profile.c:344:6: error: no previous prototype for ‘__blk_crypto_cfg_supported’ [-Werror=missing-prototypes]
344 | bool __blk_crypto_cfg_supported(struct blk_crypto_profile *profile,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
block/blk-crypto-profile.c:373:5: error: no previous prototype for ‘__blk_crypto_evict_key’ [-Werror=missing-prototypes]
373 | int __blk_crypto_evict_key(struct blk_crypto_profile *profile,
| ^~~~~~~~~~~~~~~~~~~~~~
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20221123172923.434339-1-bvanassche@acm.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 85168d416e)
Change-Id: I797a99bc00c114dc86e74e1d5b1f7866f7e64a10
Signed-off-by: Eric Biggers <ebiggers@google.com>
blk_crypto_get_keyslot, blk_crypto_put_keyslot, __blk_crypto_evict_key
and __blk_crypto_cfg_supported are only used internally by the
blk-crypto code, so move the out of blk-crypto-profile.h, which is
included by drivers that supply blk-crypto functionality.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-4-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 3569788c08)
Change-Id: I80b07a1c3b6e6f41ffe48adbdb27a3ca4480ff75
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a blk_crypto_config_supported_natively helper that wraps
__blk_crypto_cfg_supported to retrieve the crypto_profile from the
request queue. With this fscrypt can stop including
blk-crypto-profile.h and rely on the public consumer interface in
blk-crypto.h.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-3-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 6715c98b6c)
(resolved conflict in blk_crypto_config_supported())
Change-Id: I40c4ab6bd9a108661c40c837227b6aed64685ae7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Switch all public blk-crypto interfaces to use struct block_device
arguments to specify the device they operate on instead of th
request_queue, which is a block layer implementation detail.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-2-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit fce3caea0f)
(resolved conflict in blk_crypto_config_supported())
Change-Id: Ifde7cf1c8a2a5ddfb2fde4e5fb118269a3bfcdb0
Signed-off-by: Eric Biggers <ebiggers@google.com>
With below two cases, it will cause NULL pointer dereference when
accessing SM_I(sbi)->fcc_info in f2fs_issue_flush().
a) If kthread_run() fails in f2fs_create_flush_cmd_control(), it will
release SM_I(sbi)->fcc_info,
- mount -o noflush_merge /dev/vda /mnt/f2fs
- mount -o remount,flush_merge /dev/vda /mnt/f2fs -- kthread_run() fails
- dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=1 conv=fsync
b) we will never allocate memory for SM_I(sbi)->fcc_info w/ below
testcase,
- mount -o ro /dev/vda /mnt/f2fs
- mount -o rw,remount /dev/vda /mnt/f2fs
- dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=1 conv=fsync
In order to fix this issue, let change as below:
- fix error path handling in f2fs_create_flush_cmd_control().
- allocate SM_I(sbi)->fcc_info even if readonly is on.
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
... as part of setting up this branch.
Bug: 259701619
Change-Id: I4bfee9b34d63034e563af95c1aa0696418c6ec65
Signed-off-by: Will McVicker <willmcvicker@google.com>
Add inline keyword to pass compilation when CONFIG_COMPACTION is not
enabled.
include/linux/compaction.h:241:22: warning: 'isolate_and_split_free_page' defined but not used [-Wunused-function]
Bug: 175403896
Change-Id: I6bec2789a68e1b8fc9f4ea8f7267571a333d68ef
Fixes: 061e34c52e ("ANDROID: mm: compaction: fix isolate_and_split_free_page() redefinition")
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
(cherry picked from commit b9836d4090)
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
Guard isolate_and_split_free_page() with CONFIG_COMPACTION. This fixes
the follwoing build error as the function collides with its inline stub
from the header file:
mm/compaction.c:766:15: error: redefinition of ‘isolate_and_split_free_page’
766 | unsigned long isolate_and_split_free_page(struct page *page,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from mm/compaction.c:14:
./include/linux/compaction.h:241:29: note: previous definition of ‘isolate_and_split_free_page’ was here
241 | static inline unsigned long isolate_and_split_free_page(struct page *page,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: 201263307
Change-Id: Ie8f3fedcc9d4af5cfdcfd5829377671745ab77d6
Fixes: 8cd9aa93b7 ("ANDROID: implement wrapper for reverse migration")
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
Reverse migration is used to do the balancing the occupancy of memory
zones in a node in the system whose imabalance may be caused by
migration of pages to other zones by an operation, eg: hotremove and
then hotadding the same memory. In this case there is a lot of free
memory in newly hotadd memory which can be filled up by the previous
migrated pages(as part of offline/hotremove) thus may free up some
pressure in other zones of the node.
Upstream discussion: https://lore.kernel.org/all/ee78c83d-da9b-f6d1-4f66-934b7782acfb@codeaurora.org/
Bug: 201263307
Change-Id: Ib3137dab0db66ecf6858c4077dcadb9dfd0c6b1c
Signed-off-by: Charan Teja Reddy <quic_charante@quicinc.com>
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
