In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops, as reported by Anand Moon.
Fixed it by using IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny
Reported-by: Anand Moon
---
Tested on Odroid XU4/HC1, kernel 4.15 with following command:
fallocate -
Am Montag, 5. Februar 2018, 15:02:03 CET schrieb Jonathan Cameron:
Hi Jonathan,
> I could drop this for the initial submission and bring it in as an
> optimization with supporting numbers as a follow up patch.
I am not disputing the code itself. It just occurred to me that the code is
similar t
On Mon, 2018-02-05 at 08:45 +, Horia Geantă wrote:
> On 2/2/2018 2:54 PM, Auer, Lukas wrote:
> > On Fri, 2018-02-02 at 11:20 +, Bryan O'Donoghue wrote:
> > > On 01/02/18 12:16, Horia Geantă wrote:
> > > > If the loop cannot exit based on value of "ret" != -EAGAIN,
> > > > then it
> > > > me
On Sat, 3 Feb 2018 12:16:18 +0100
Stephan Müller wrote:
> Am Dienstag, 30. Januar 2018, 16:29:52 CET schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > + /* Special path for single element SGLs with small packets. */
> > + if (sg_is_last(sgl) && sgl->length <= SEC_SMALL_PACKET_SIZE) {
>
>
In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
with -ENODEV, caam_probe() enters an endless loop:
run_descriptor_deco0
ret -ENODEV
-> instantiate_rng
-ENODEV, overwritten by -EAGAIN
ret -EAGAIN
-> caam_probe
On 2/2/2018 2:54 PM, Auer, Lukas wrote:
> On Fri, 2018-02-02 at 11:20 +, Bryan O'Donoghue wrote:
>> On 01/02/18 12:16, Horia Geantă wrote:
>>> If the loop cannot exit based on value of "ret" != -EAGAIN, then it
>>> means
>>> caam_probe() will eventually fail due to ret == -EAGAIN:
>>> if (r
