aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-07-05ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEMEJann Horn1-3/+1
Fix two issues: When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU reference to the parent's objective credentials, then give that pointer to get_cred(). However, the object lifetime rules for things like struct cred do not permit unconditionally turning an RCU reference into a stable reference. PTRACE_TRACEME records the parent's credentials as if the parent was acting as the subject, but that's not the case. If a malicious unprivileged child uses PTRACE_TRACEME and the parent is privileged, and at a later point, the parent process becomes attacker-controlled (because it drops privileges and calls execve()), the attacker ends up with control over two processes with a privileged ptrace relationship, which can be abused to ptrace a suid binary and obtain root privileges. Fix both of these by always recording the credentials of the process that is requesting the creation of the ptrace relationship: current_cred() can't change under us, and current is the proper subject for access control. This change is theoretically userspace-visible, but I am not aware of any code that it will actually break. Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP") Signed-off-by: Jann Horn <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2019-07-04Merge remote-tracking branch 'spi/topic/pump-rt' into spi-nextMark Brown2-6/+32
2019-07-04Merge branch 'spi-5.3' into spi-nextMark Brown33-540/+2283
2019-07-04Merge branch 'spi-5.2' into spi-linusMark Brown3-13/+59
2019-07-04Merge remote-tracking branch 'regulator/topic/coupled' into regulator-nextMark Brown5-75/+287
2019-07-04Merge branch 'regulator-5.3' into regulator-nextMark Brown46-676/+2553
2019-07-04Merge branch 'regulator-5.2' into regulator-linusMark Brown3-11/+22
2019-07-04Merge branch 'regmap-5.3' into regmap-nextMark Brown5-6/+89
2019-07-04Merge branch 'regmap-5.2' into regmap-linusMark Brown2-0/+4
2019-07-04regulator: max77650: use vsel_stepBartosz Golaszewski1-64/+9
Use the new vsel_step field in the regulator description to instruct the regulator API on the required voltage ramping. Switch to using the generic regmap helpers for voltage setting and remove the old set_voltage callback that handcoded the selector stepping. Signed-off-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-07-04regulator: implement selector steppingBartosz Golaszewski2-0/+69
Some regulators require that the requested voltage be reached gradually by setting all or some of the intermediate values. Implement a new field in the regulator description struct that allows users to specify the number of selectors by which the regulator API should step when ramping the voltage up/down. Signed-off-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-07-04Merge branches 'x86/vt-d', 'x86/amd', 'arm/smmu', 'arm/omap', ↵Joerg Roedel9583-63346/+20879
'generic-dma-ops' and 'core' into next
2019-07-04iommu/omap: No need to check return value of debugfs_create functionsGreg Kroah-Hartman1-29/+6
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Joerg Roedel <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-07-04regmap: select CONFIG_REGMAP while REGMAP_SCCB is setYueHaibing1-1/+1
REGMAP_SCCB is selected by ov772x and ov9650 drivers, but CONFIG_REGMAP may not, so building will fails: rivers/media/i2c/ov772x.c: In function ov772x_probe: drivers/media/i2c/ov772x.c:1360:22: error: variable ov772x_regmap_config has initializer but incomplete type static const struct regmap_config ov772x_regmap_config = { ^~~~~~~~~~~~~ drivers/media/i2c/ov772x.c:1361:4: error: const struct regmap_config has no member named reg_bits Reported-by: Hulk Robot <[email protected]> Fixes: 5bbf32217bf9 ("media: ov772x: use SCCB regmap") Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-07-04s390/pci: correctly handle MIO opt-outSebastian Ott1-1/+1
Do not issue CLP_SET_ENABLE_MIO after opting out of MIO instruction usage. This should not fix a bug but reduce overhead within firmware. Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-07-04s390/pci: deal with devices that have no support for MIO instructionsSebastian Ott2-7/+13
Unfortunately we have to handle a class of devices that don't support the new MIO instructions. Adjust resource assignment and mapping accordingly. Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-07-04drm/imx: only send event on crtc disable if kept disabledRobert Beckett1-1/+1
The event will be sent as part of the vblank enable during the modeset if the crtc is not being kept disabled. Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration") Signed-off-by: Robert Beckett <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
2019-07-04drm/imx: notify drm core before sending event during crtc disableRobert Beckett1-2/+2
Notify drm core before sending pending events during crtc disable. This fixes the first event after disable having an old stale timestamp by having drm_crtc_vblank_off update the timestamp to now. This was seen while debugging weston log message: Warning: computed repaint delay is insane: -8212 msec This occurred due to: 1. driver starts up 2. fbcon comes along and restores fbdev, enabling vblank 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank seq number and time set at current value (some time later) 4. weston starts and does a modeset 5. atomic commit disables crtc while it does the modeset 6. ipu_crtc_atomic_disable sends vblank with old seq number and time Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression") Signed-off-by: Robert Beckett <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
2019-07-04i3c: master: Use struct_size() helperGustavo A. R. Silva1-3/+2
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(*defslvs) + ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc)) with: struct_size(defslvs, slaves, ndevs - 1) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Boris Brezillon <[email protected]>
2019-07-04dt-bindings: i3c: cdns: Use correct cells for I2C deviceQii Wang1-1/+1
I2C device reg should be "reg = <0x52 0x0 0x10>;" Fixes: e29d0d9c90c9 ("dt-bindings: i3c: Document Cadence I3C master bindings") Signed-off-by: Qii Wang <[email protected]> Signed-off-by: Boris Brezillon <[email protected]>
2019-07-04iommu/arm-smmu-v3: Invalidate ATC when detaching a deviceJean-Philippe Brucker1-1/+4
We make the invalid assumption in arm_smmu_detach_dev() that the ATC is clear after calling pci_disable_ats(). For one thing, only enabling the PCIe ATS capability constitutes an implicit invalidation event, so the comment was wrong. More importantly, the ATS capability isn't necessarily disabled by pci_disable_ats() in a PF, if the associated VFs have ATS enabled. Explicitly invalidate all ATC entries in arm_smmu_detach_dev(). The endpoint cannot form new ATC entries because STE.EATS is clear. Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS") Reported-by: Manoj Kumar <[email protected]> Reported-by: Robin Murphy <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-07-04gpio: stp-xway: allow compile-testingMartin Blumenstingl1-1/+2
Enable compile-testing of the stp-xway GPIO driver now that it does not depend on any architecture specific includes anymore. Signed-off-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpio: stp-xway: get rid of the #include <lantiq_soc.h> dependencyMartin Blumenstingl1-4/+1
Use the xway_stp_{r,w}32 helpers in xway_stp_w32_mask instead of relying on ltq_{r,w}32 from the architecture specific <lantiq_soc.h>. This will allow the driver to be compile-tested on all architectures that support MMIO. Signed-off-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpio: stp-xway: improve module clock error handlingMartin Blumenstingl1-3/+8
Three module clock error handling improvements: - use devm_clk_get() so the clock instance can be freed if devm_gpiochip_add_data() fails later on - switch to clk_prepare_enable() so the driver is ready whenever the lantiq target switches to the common clock framework - disable the clock again (using clk_disable_unprepare()) if devm_gpiochip_add_data() All of these are virtually no-ops with the current lantiq target. However, these will be relevant if we switch to the common clock framework. Signed-off-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpio: stp-xway: simplify error handling in xway_stp_probe()Martin Blumenstingl1-10/+9
Return early if devm_gpiochip_add_data() returns an error instead of having two consecutive "if (!ret) ..." statements. Also make xway_stp_hw_init() return void because it unconditionally returns 0. While here also update the kerneldoc comment for xway_stp_hw_init(). These changes makes the error handling within the driver consistent. No functional changes intended. Signed-off-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpiolib: Clarify use of non-sleeping functionsGeert Uytterhoeven1-8/+8
Obviously functions that are safe to be called from atomic contexts, can be called from non-atomic contexts, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variantsGeert Uytterhoeven1-3/+4
Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed the functions to use a "gpiod" prefix, and commit 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface") introduced the "raw" variants, but both changes forgot to update the comments. Readd a similar reference to gpiod_set_value(), which was accidentally removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()"). Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04gpiolib: Document new gpio_chip.init_valid_mask fieldGeert Uytterhoeven1-0/+2
A new field init_valid_mask was added to struct gpio_chip, but it was not documented. Fixes: f8ec92a9f63b3b11 ("gpiolib: Add init_valid_mask exported function") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04Documentation: gpio: Fix reference to gpiod_get_array()Geert Uytterhoeven1-1/+1
The function is called gpiod_get_array(), not gpiod_array_get(). Fixes: 77588c14ac868cae ("gpiolib: Pass array info to get/set array functions") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2019-07-04Merge tag 'trace-v5.2-rc5' of ↵Linus Torvalds3-14/+30
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "This includes three fixes: - Fix a deadlock from a previous fix to keep module loading and function tracing text modifications from stepping on each other (this has a few patches to help document the issue in comments) - Fix a crash when the snapshot buffer gets out of sync with the main ring buffer - Fix a memory leak when reading the memory logs" * tag 'trace-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare() tracing/snapshot: Resize spare buffer if size changed tracing: Fix memory leak in tracing_err_log_open() ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare() ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()
2019-07-04Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Dave Airlie1-2/+5
into drm-fixes Fix a kernel nullptr deref on module unload when any etnaviv GPU failed to initialize properly. Signed-off-by: Dave Airlie <[email protected]> From: Lucas Stach <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-07-04Merge tag 'drm-misc-fixes-2019-07-03' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes panfrost- Avoid double free by deleting GEM handle in create_bo failure path (Boris) Cc: Boris Brezillon <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20190704001302.GA260390@art_vandelay
2019-07-04Merge tag 'drm-fixes-5.2-2019-07-02' of ↵Dave Airlie5-21/+9
git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.2-2019-07-02: Fixes for stable amdgpu: - stability fix for gfx9 - regression fix for HG on some polaris boards - crash fix for some new OEM boards Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-07-04Merge tag 'gpio-v5.2-4' of ↵Linus Torvalds1-1/+8
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fix from Linus Walleij: "A single fixup for the SPI CS gpios that regressed in the current kernel cycle" * tag 'gpio-v5.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio/spi: Fix spi-gpio regression on active high CS
2019-07-03nfsd: Fix overflow causing non-working mounts on 1 TB machinesPaul Menzel1-1/+1
Since commit 10a68cdf10 (nfsd: fix performance-limiting session calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with 1 TB of memory cannot be mounted anymore. The mount just hangs on the client. The gist of commit 10a68cdf10 is the change below. -avail = clamp_t(int, avail, slotsize, avail/3); +avail = clamp_t(int, avail, slotsize, total_avail/3); Here are the macros. #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi) `total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts the values to `int`, which for 32-bit integers can only hold values −2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1). `avail` (in the function signature) is just 65536, so that no overflow was happening. Before the commit the assignment would result in 21845, and `num = 4`. When using `total_avail`, it is causing the assignment to be 18446744072226137429 (printed as %lu), and `num` is then 4164608182. My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the server thinks there is no memory available any more for this client. Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long` fixes the issue. Now, `avail = 65536` (before commit 10a68cdf10 `avail = 21845`), but `num = 4` remains the same. Fixes: c54f24e338ed (nfsd: fix performance-limiting session calculation) Cc: [email protected] Signed-off-by: Paul Menzel <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
2019-07-03x86/fsgsbase: Revert FSGSBASE supportThomas Gleixner11-537/+50
The FSGSBASE series turned out to have serious bugs and there is still an open issue which is not fully understood yet. The confidence in those changes has become close to zero especially as the test cases which have been shipped with that series were obviously never run before sending the final series out to LKML. ./fsgsbase_64 >/dev/null Segmentation fault As the merge window is close, the only sane decision is to revert FSGSBASE support. The revert is necessary as this branch has been merged into perf/core already and rebasing all of that a few days before the merge window is not the most brilliant idea. I could definitely slap myself for not noticing the test case fail when merging that series, but TBH my expectations weren't that low back then. Won't happen again. Revert the following commits: 539bca535dec ("x86/entry/64: Fix and clean up paranoid_exit") 2c7b5ac5d5a9 ("Documentation/x86/64: Add documentation for GS/FS addressing mode") f987c955c745 ("x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2") 2032f1f96ee0 ("x86/cpu: Enable FSGSBASE on 64bit by default and add a chicken bit") 5bf0cab60ee2 ("x86/entry/64: Document GSBASE handling in the paranoid path") 708078f65721 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit") 79e1932fa3ce ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro") 1d07316b1363 ("x86/entry/64: Switch CR3 before SWAPGS in paranoid entry") f60a83df4593 ("x86/process/64: Use FSGSBASE instructions on thread copy and ptrace") 1ab5f3f7fe3d ("x86/process/64: Use FSBSBASE in switch_to() if available") a86b4625138d ("x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions") 8b71340d702e ("x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions") b64ed19b93c3 ("x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE") Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Chang S. Bae <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ravi Shankar <[email protected]> Cc: Dave Hansen <[email protected]> Cc: H. Peter Anvin <[email protected]>
2019-07-03selftests/x86/fsgsbase: Fix some test case bugsAndy Lutomirski1-34/+40
This refactors do_unexpected_base() to clean up some code. It also fixes the following bugs in test_ptrace_write_gsbase(): - Incorrect printf() format string caused crashes. - Hardcoded 0x7 for the gs selector was not reliably correct. It also documents the fact that the test is expected to fail on old kernels. Fixes: a87730cc3acc ("selftests/x86/fsgsbase: Test ptracer-induced GSBASE write with FSGSBASE") Fixes: 1b6858d5a2eb ("selftests/x86/fsgsbase: Test ptracer-induced GSBASE write") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: "BaeChang Seok" <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: "H . Peter Anvin" <[email protected]> Cc: Andi Kleen <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: "BaeChang Seok" <[email protected]> Link: https://lkml.kernel.org/r/bab29c84f2475e2c30ddb00f1b877fcd7f4f96a8.1562125333.git.luto@kernel.org
2019-07-03crypto: stm32/hash - remove interruptible condition for dmaLionel Debieve1-2/+2
When DMA is used, waiting for completion must not be interruptible as it can generate an error that is not handle by the driver. There is no need to put the completion interruptible in this driver. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: stm32/hash - Fix hmac issue more than 256 bytesLionel Debieve1-1/+1
Correct condition for the second hmac loop. Key must be only set in the first loop. Initial condition was wrong, HMAC_KEY flag was not properly checked. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: stm32/crc32 - rename driver fileLionel Debieve2-1/+1
Use the same naming convention for all stm32 crypto drivers. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: amcc - remove memset after dma_alloc_coherentFuqian Huang1-1/+0
In commit af7ddd8a627c ("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"), dma_alloc_coherent has already zeroed the memory. So memset is not needed. Signed-off-by: Fuqian Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: ccp - Switch to SPDX license identifiersHook, Gary22-88/+20
Add an SPDX identifier and remove any specific statements. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: ccp - Validate the the error value used to index error messagesHook, Gary2-46/+52
The error code read from the queue status register is only 6 bits wide, but we need to verify its value is within range before indexing the error messages. Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable") Cc: <[email protected]> Reported-by: Cfir Cohen <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: doc - Fix formatting of new crypto engine contentHook, Gary1-38/+73
Tidy up the formatting/grammar in crypto_engine.rst. Use bulleted lists where appropriate. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: doc - Add parameter documentationHook, Gary2-1/+12
Fill in missing parameter descriptions for the compression algorithm, then pick them up to document for the compression_alg structure. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTRArd Biesheuvel3-31/+75
This implements 5-way interleaving for ECB, CBC decryption and CTR, resulting in a speedup of ~11% on Marvell ThunderX2, which has a very deep pipeline and therefore a high issue latency for NEON instructions operating on the same registers. Note that XTS is left alone: implementing 5-way interleave there would either involve spilling of the calculated tweaks to the stack, or recalculating them after the encryption operation, and doing either of those would most likely penalize low end cores. For ECB, this is not a concern at all, given that we have plenty of spare registers. For CTR and CBC decryption, we take advantage of the fact that v16 is not used by the CE version of the code (which is the only one targeted by the optimization), and so we can reshuffle the code a bit and avoid having to spill to memory (with the exception of one extra reload in the CBC routine) Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: arm64/aes-ce - add 5 way interleave routinesArd Biesheuvel3-68/+52
In preparation of tweaking the accelerated AES chaining mode routines to be able to use a 5-way stride, implement the core routines to support processing 5 blocks of input at a time. While at it, drop the 2 way versions, which have been unused for a while now. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - drop icv_oolChristophe Leroy2-5/+0
icv_ool is not used anymore, drop it. Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - fix hash on SEC1.Christophe Leroy1-28/+41
On SEC1, hash provides wrong result when performing hashing in several steps with input data SG list has more than one element. This was detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS: [ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector 6, cfg="random: may_sleep use_finup src_divs=[<reimport>25.88%@+8063, <flush>24.19%@+9588, 28.63%@+16333, <reimport>4.60%@+6756, 16.70%@+16281] dst_divs=[71.61%@alignmask+16361, 14.36%@+7756, 14.3%@+" [ 44.325122] alg: hash: sha1-talitos test failed (wrong result) on test vector 3, cfg="random: inplace use_final src_divs=[<flush,nosimd>16.56%@+16378, <reimport>52.0%@+16329, 21.42%@alignmask+16380, 10.2%@alignmask+16380] iv_offset=39" [ 44.493500] alg: hash: sha224-talitos test failed (wrong result) on test vector 4, cfg="random: use_final nosimd src_divs=[<reimport>52.27%@+7401, <reimport>17.34%@+16285, <flush>17.71%@+26, 12.68%@+10644] iv_offset=43" [ 44.673262] alg: hash: sha256-talitos test failed (wrong result) on test vector 4, cfg="random: may_sleep use_finup src_divs=[<reimport>60.6%@+12790, 17.86%@+1329, <reimport>12.64%@alignmask+16300, 8.29%@+15, 0.40%@+13506, <reimport>0.51%@+16322, <reimport>0.24%@+16339] dst_divs" This is due to two issues: - We have an overlap between the buffer used for copying the input data (SEC1 doesn't do scatter/gather) and the chained descriptor. - Data copy is wrong when the previous hash left less than one blocksize of data to hash, implying a complement of the previous block with a few bytes from the new request. Fix it by: - Moving the second descriptor after the buffer, as moving the buffer after the descriptor would make it more complex for other cipher operations (AEAD, ABLKCIPHER) - Skip the bytes taken from the new request to complete the previous one by moving the SG list forward. Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Cc: [email protected] Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - move struct talitos_edesc into talitos.hChristophe Leroy2-30/+30
Moves struct talitos_edesc into talitos.h so that it can be used from any place in talitos.c It will be required for next patch ("crypto: talitos - fix hash on SEC1") Signed-off-by: Christophe Leroy <[email protected]> Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.