FIPS 140-3 requires this for some reason.
Bug: 188620248
Change-Id: I7c286532097e1d8971faf4d8be31b801f9007e3b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c14d52059b)
The lab has confirmed that it is actually fine for users to keep using
non-FIPS code after the module has loaded if they were already using it
beforehand. So remove the code that tried to prevent this by updating
live algorithms in-place. Similarly, remove the call to
synchronize_rcu_tasks() which no longer has any purpose.
We still need to move the live algorithms to a private list, so keep
doing that. Keep appending "+orig" to cra_name as well, and start doing
the same for cra_driver_name too.
Bug: 188620248
Change-Id: I29c9faec7d7314484a03f9729924b2f892552c7c
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 54aecb72db)
As per the new guidance from the lab, the module must block crypto
operations until the tests have completed. It's unclear what this means
exactly (given that technically this is impossible), but let's make some
changes that should be enough to comply with the requirement's intent.
First, register the library functions and update the live algorithms
after the tests rather than before the tests. This is a trivial change.
Much more problematic is the fact that the algorithms are registered
with the kernel's crypto framework before the tests run, as the tests
depend on the framework. Unfortunately, the lab believes that the
kernel isn't allowed to enforce the ordering here; the module itself
must. Moreover, trying to solve this by copying the crypto API
framework into the module proved to be heavily problematic.
Thus, implement an alternate solution: make the module override the tfm
initialization function of every algorithm it registers, so that it can
wait for the tests to complete before allowing the use of any algorithm.
This is sufficient if the user makes a supported sequence of API calls.
Bug: 153614920
Bug: 188620248
Change-Id: I11ffba90c08114dda4e91c4be7ce8b608c4e14c1
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 02e48f383b)
Instead of having a special case in the core kernel's module loader that
treats a module called 'fips140.ko' in a special way, use a host tool to
tweak the ELF metadata of this module so that the RELA data is preserved
and accessible to the module init code.
This is done in the following way:
- each RELA section that we care about (the ones for .text and .rodata
at the moment) is copied into a new section called .init.rela.<name>
with the SHF_ALLOC attribute, so that the module loader will copy it
into __init memory at load time;
- for each such section, an offset/count tuple is added as a global
variable to the module;
- the count field of those tuples is populated directly by the host tool
based on the actual size of the RELA section in question;
- the offset field is decorated with a place-relative relocation against
the start of the copied RELA section via a weak symbol reference,
which causes an entry to be emitted into the ELF symbol table;
- these ELF symbol table entries are updated by the host tool and turned
into STT_SECTION type symbols with STB_GLOBAL linkage, carrying the
correct section index.
With these changes in place, the unmodified module loader will load all
required information into memory in a way that permits the module init
code to locate the relocations, and apply them in reverse.
Bug: 153614920
Bug: 188620248
Change-Id: I07d9704febdf913834502dd09c19aa4a04d983b1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 502af6e349)
We currently only emit directives for handling the .text section into
the module linker script if both LTO and CFI are enabled, while for
other sections, we do this even if CFI is not enabled. This is
inconsistent at best, but as it also interferes with the assumption in
the fips140.ko module that the .text._start and .text._end input
sections are placed at the very start and end of the .text section,
which currently can only be relied upon if CFI is enabled.
So rearrange the #ifdef so that it only covers the .text.__cfi_check
input section. Note that aligning to page size is likely to be redundant
in any case, given that the .text section is laid out first, and module
allocations are page aligned to begin with, so making that part
unconditional is unlikely to make an observeable difference in the
output.
Bug: 153614920
Bug: 188620248
Fixes: 6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
Change-Id: I3f9ed0ae8fa8fe5693c8d2964566cbb42c101aa7
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 6ae8277450)
These flags are supposed to be used when building all source files for
the module.
Bug: 188620248
Fixes: b7397e89db ("ANDROID: fips140: add power-up cryptographic self-tests")
Change-Id: I41cacff040c8a8a0065dd3cfc537303f1ff18335
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 422bc2feb7)
Unfortunately, the AES-GCM implementations won't actually be able to be
FIPS-approved. One consequence of this is that the "cmac" template will
need to be tested with all underlying "aes" implementations, as the
equivalent test with "gcm" won't count as fulfilling the requirement to
test all AES implementations in an authenticated mode when supported.
Update the self-tests and comments accordingly.
Bug: 153614920
Bug: 188620248
Change-Id: I874b0718a5ff9d4e2dea2353448266e87f3f0d0b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit a9765fb6dc)
Although jitterentropy doesn't necessarily need to be part of
fips140.ko, it does need to have the SP800-90B health tests enabled, and
that requires that it be compiled with the fips_enabled flag set. The
easiest way to do this is just to include a copy of it in fips140.ko.
Bug: 153614920
Bug: 188620248
Change-Id: I9dc0281e07e08e0650e3d340897c697722ad3b1a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit cae2421105)
AES-CMAC is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cmac" template. Add the "cmac" template
to fips140.ko too and add a self-test for AES-CMAC, so that we can
include AES-CMAC in the set of algorithms which will be certified.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms.
Bug: 153614920
Bug: 188620248
Change-Id: I6c1d9281fe848a7101d5ef94ab48e5a41bbcc6f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 038dc9f2cc)
AES-CBC-CTS is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cts" template. Add the "cts" template
to fips140.ko too and add a self-test for AES-CBC-CTS, so that we can
include AES-CBC-CTS in the set of algorithms which will be certified.
There appears to be no support for CBC-CTS mode in pycryptodome or
python-cryptography, so I manually added the test vector.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms. Android uses AES-CBC-CTS for filenames
encryption, which may be relevant (though arguably this use case doesn't
actually require a FIPS approved algorithm).
Bug: 153614920
Bug: 188620248
Change-Id: I53ffbd1d38493592eeaf471bc0007978ec400878
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit e2cfdfbc51)
The lab has confirmed that this test is not required.
Bug: 153614920
Bug: 188620248
Change-Id: Ie55031beacd00f093db3a7ba30fe0844a2ce363b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit ea902862ea)
By using the initial_value parameter when creating the pycryptodome
AES-CTR instance, we can use any 16-byte IV, like the other AES modes.
Therefore, there's no need for the last 4 bytes of the IV to be 0.
This doesn't really matter, but it seems nice to avoid this quirk.
Bug: 153614920
Bug: 188620248
Change-Id: If33de260b1119f2b3e004164199b08364781ab23
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fa5a44b364)
Test all implementations of each algorithm rather than just the highest
priority implementation. This aligns with the revised guidance we have
received from the lab.
We can still skip some tests in some cases, as per the FIPS 140-2
Implementation Guidance document. See the comments for details.
To align with the new scope of the tests, the fips140.broken_alg module
parameter now must specify an implementation (e.g. "sha256-ce") rather
than an algorithm (e.g. "sha256").
No change to the DRBG tests is required, as it turns out the module only
includes HMAC_DRBG. However, clarify the comment about the DRBG tests.
On a Pixel device, this increases the running time of the fips140 tests
from 0.5ms to 3.1 ms (very roughly; there's a lot of variation). This
is still very fast, so it isn't expected to be a problem.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Change-Id: I555b535dd45f0164b7744a2c9338c501bb88de86
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit abe0780696)
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components.
android_vh_snd_soc_card_get_comp_chain can be registered here
to allows DAI/component chaining.
Later PCM operations can be called for all these listed components for a
valid DAPM path.
ALSA machine driver can setup component_chaining like below code slice.
static void my_board_component_chaining_hook(void *data, bool *ret)
{
*ret = true;
}
static int my_board_dev_probe(struct platform_device *pdev)
{
register_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static int my_board_dev_remove(struct platform_device *pdev)
{
unregister_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static struct platform_driver my_board_driver = {
...
.probe = my_board_dev_probe,
.remove = my_board_dev_remove,
...
};
Bug: 198732156
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.com>
Change-Id: Ife5df291d40af9ec83d57462b6a08aba95d9119d
The ABI diff is essentially bogus, but included here for completeness.
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct xhci_hcd at xhci.h:1756:1' changed:
type size hasn't changed
1 data member deletion:
'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide322; union {};}', at offset 59392 (in bits) at xhci.h:1935:1
18 impacted interfaces
Bug: 210255585
Change-Id: Ic646e0edd2ab19fcd9b7b88b6e6a604299fc4824
Signed-off-by: Giuliano Procida <gprocida@google.com>
The __UNIQUE_ID() macro causes problems as it turns out to not be
deterministic across different compiler runs as it relies on the
__COUNTER__ macro which could have been used on other .h files previous
to this .h file being included.
This shows up specifically when building with "LTO=thin" vs. "LTO=full"
as different build paths seem to be triggered.
As the structure name isn't really needed at all here, we were just
including it for older compilers that could not handle anonymous
structures in a union, just drop the whole thing which resolves the abi
naming issue.
Bug: 210255585
Reported-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6b9449fa9d26ffc5d66b2f0f3b41e2d5f3003f68
Commit f1a0a376ca ("sched/core: Initialize the idle task with
preemption disabled") removed the init_idle() call from
idle_thread_get(). This was the sole call-path on hotplug that resets
the Shadow Call Stack (scs) Stack Pointer (sp).
Not resetting the scs-sp leads to scs overflow after enough hotplug
cycles. Therefore add an explicit scs_task_reset() to the hotplug code
to make sure the scs-sp does get reset on hotplug.
Fixes: f1a0a376ca ("sched/core: Initialize the idle task with preemption disabled")
Signed-off-by: Woody Lin <woodylin@google.com>
[peterz: Changelog]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lore.kernel.org/r/20211012083521.973587-1-woodylin@google.com
(cherry picked from commit 63acd42c0d)
Bug: 201047587
Bug: 201771367
Change-Id: I9e48270f8d4c698c140cc3f427cadae636acb6d7
Add define of cpuset_update_active_cpus_affine() for fix compile error
when not define CONFIG_CPUSETS.
Bug: 204347727
Fixes: 09bd9e940e ("ANDROID: cpuhp/pause: schedule cpu_hotplug_work on
resume cpu")
Change-Id: Icf79df5e22233d15e4e8257a5f54176efbcd975b
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
Enable the UVC function driver to allow USB gadgets
to connect as a standard video device to a host.
Bug: 200712777
Signed-off-by: Dan Vacura <w36195@motorola.com>
Change-Id: Ia037f8560664f9e98f28f3fede609764d5d5699d
The missing leading whitespace in android/abi_gki_aarch64_galaxy
caused its symbols to be dropped from the distribution
abi_symbollist file and the distribution vmlinux binary.
Bug: 203852249
Change-Id: I7854401e0a55ad89beacde588c24f1d1698e9e17
Signed-off-by: Giuliano Procida <gprocida@google.com>
This reverts commit 1aa1f6a7cf.
The hook android_vh_mpam_set is not used by any vendor, so remove
it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 165333282
Cc: C-J.Chen <C-J.Chen@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I18356743538df7d41a00f54479bf2a0bc3a62e06
On the android12-5.10 branch, commit 4a5cf92412 ("BACKPORT: FROMGIT:
userfaultfd: add UFFDIO_CONTINUE ioctl") added a new call site for the
function validate_range(). Meanwhile, on the 5.10 stable branch, commit
0b591c020d ("userfaultfd: do not untag user pointers") changed the
function signature of validate_range() and updated all call sites
accordingly. However, since these two commits happened on different
branches, the new call site in userfaultfd_continue() has not been
updated accordingly. This has arguably been missed in the merge commit
66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into
android12-5.10").
This patch fixes the following build breakage
./common/fs/userfaultfd.c:1875:32: error: incompatible pointer to integer conversion passing '__u64 *' (aka 'unsigned long long *') to parameter of type '__u64' (aka 'unsigned long long'); remove & [-Werror,-Wint-conversion]
ret = validate_range(ctx->mm, &uffdio_continue.range.start,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./common/fs/userfaultfd.c:1245:14: note: passing argument to parameter 'start' here
__u64 start, __u64 len)
^
1 error generated.
Fixes: 66379c1ee5 ("Merge tag 'android12-5.10.66_r00' into android12-5.10")
Signed-off-by: Aaron Ding <aaronding@google.com>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I7ad40df213897314c439480f22a2ef4712e84025
(cherry picked from commit 5ec931a853)
Resume cpu need to run cpuset_hotplug_workfn which need take
about several milliseconds, and even more if the system have
more tasks.
This isn't suitable to run in the main task context of resume
cpu.
Due to the cpu which is resuming only have active mask,
but still not rebuild sched domain, make this slow
work run on resuming cpu can not take extra overload to
previous active cpus.
Bug: 203839955
Fixes: 1d3a64fbd2 ("ANDROID: cpu/hotplug: rebuild sched
domains immediately")
Change-Id: Ia7bdd077f982950c02696c3598a41b2482046220
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
This reverts commit c82dbcbec1.
Reason for revert: use vendor_hook approach instead of adding a new field.
Change-Id: I001dafc1b90cfe4567a13f538c2f8d25a0929504
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.corp-partner.google.com>
Some functions may dynamically enable and disable their endpoints
regularly throughout their operation, particularly when Set Interface
is employed to switch between Alternate Settings. For instance the
UAC2 function has its respective endpoints for playback & capture
associated with AltSetting 1, in which case those endpoints would not
get enabled until the host activates the AltSetting. And they
conversely become disabled when the interfaces' AltSetting 0 is
chosen.
With the DWC3 FIFO resizing algorithm recently added, every
usb_ep_enable() call results in a call to resize that EP's TXFIFO,
but if the same endpoint is enabled again and again, this incorrectly
leads to FIFO RAM allocation exhaustion as the mechanism did not
account for the possibility that endpoints can be re-enabled many
times.
Example log splat:
dwc3 a600000.dwc3: Fifosize(3717) > RAM size(3462) ep3in depth:217973127
configfs-gadget gadget: u_audio_start_capture:521 Error!
dwc3 a600000.dwc3: request 000000000be13e18 was not queued to ep3in
Add another bit DWC3_EP_TXFIFO_RESIZED to dep->flags to keep track of
whether an EP had already been resized in the current configuration.
If so, bail out of dwc3_gadget_resize_tx_fifos() to avoid the
calculation error resulting from accumulating the EP's FIFO depth
repeatedly. This flag is retained across multiple ep_disable() and
ep_enable() calls and is cleared when GTXFIFOSIZn is reset in
dwc3_gadget_clear_tx_fifos() upon receiving the next Set Config.
Fixes: 9f607a309f ("usb: dwc3: Resize TX FIFOs to meet EP bursting requirements")
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20211021180129.27938-1-jackp@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 876a75cb52https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Bug: 204047971
Change-Id: Ia104c2fa9be36182a23a7e6f923e499ef3bcc3b1
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
In system_heap_do_allocate, we will use uncached heap device to call
dma_map_sgtable & dma_unmap_sgtable to do implicitly flush.
However, device of uncached heap is not set dma_parms, default value(64KB)
is too small for dma_heap buffer, it will cause some warning log below when
CONFIG_DMA_API_DEBUG_SG is enabled.
warning log sample:
|DMA-API: dma_heap system-uncached: mapping sg segment longer than device claims to support [len=1048576] [max=65536]
|WARNING: CPU: 4 PID: 576 at kernel/dma/debug.c:1173 debug_dma_map_sg+0x214/0x438
|......
Bug: 199986022
Change-Id: I97076de329f4a50d035d43d69cb17606064c3151
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
CONFIG_UBSAN_MISC is seperated to individual options and
no longer existed in configuration. Hence, remove the
entry from gki_defconfig. The other UBSAN configs are
unset to align with android-mainline.
Bug: 199373673
Ref: https://android-review.googlesource.com/c/kernel/common/+/1584824
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: I9f525fcd386eb7cc2503afb130a5230b5e730bee
Since GCC 8.0 -fsanitize=signed-integer-overflow doesn't work with
-fwrapv. -fwrapv makes signed overflows defines and GCC essentially
disables ubsan checks. On GCC < 8.0 -fwrapv doesn't have influence on
-fsanitize=signed-integer-overflow setting, so it kinda works but
generates false-positves and violates uaccess rules:
lib/iov_iter.o: warning: objtool: iovec_from_user()+0x22d: call to
__ubsan_handle_add_overflow() with UACCESS enabled
Disable signed overflow checks to avoid these problems. Remove unsigned
overflow checks as well. Unsigned overflow appeared as side effect of
commit cdf8a76fda ("ubsan: move cc-option tests into Kconfig"), but it
never worked (kernel doesn't boot). And unsigned overflows are allowed by
C standard, so it just pointless.
Link: https://lkml.kernel.org/r/20210209232348.20510-1-ryabinin.a.a@gmail.com
Signed-off-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 199373673
(cherry picked from commit 6aaa31aeb9)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: I7f0e9d7a4d7c69c21e42bd21070c5d265bddbff1
Building ubsan kernels even for compile-testing introduced these
warnings in my randconfig environment:
crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
static void blake2b_compress(struct blake2b_state *S,
crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
static void sha512_generic_block_fn(struct sha512_state *sst, u8 const *src,
lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180 bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
static noinline void fe_mul_impl(u32 out[10], const u32 in1[10], const u32 in2[10])
lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588 bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
static noinline void fe_sqr_impl(u32 out[10], const u32 in1[10])
Further testing showed that this is caused by
-fsanitize=unsigned-integer-overflow, but is isolated to the 32-bit x86
architecture.
The one in blake2b immediately overflows the 8KB stack area
architectures, so better ensure this never happens by disabling the
option for 32-bit x86.
Link: https://lkml.kernel.org/r/20210112202922.2454435-1-arnd@kernel.org
Link: https://lore.kernel.org/lkml/20201230154749.746641-1-arnd@kernel.org/
Fixes: d0a3ac549f ("ubsan: enable for all*config builds")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Marco Elver <elver@google.com>
Cc: George Popescu <georgepope@android.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 199373673
(cherry picked from commit 251b5497c5)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: I1855d47cb0525cdbf523fced4cbb75189dbb6f32
