Hi Herbert,
On Fri, Dec 01, 2017 at 11:31:09AM +1100, Herbert Xu wrote:
> On Thu, Nov 30, 2017 at 10:19:26AM +0100, Kamil Konieczny wrote:
> >
> > can the driver get request for final/finup/digest with null req->result ?
> > If yes (?), such checks can be done before any hardware processing, savin
Hi All,
On 01.12.2017 09:11, Antoine Tenart wrote:
> Hi Herbert,
>
> On Fri, Dec 01, 2017 at 11:31:09AM +1100, Herbert Xu wrote:
>> On Thu, Nov 30, 2017 at 10:19:26AM +0100, Kamil Konieczny wrote:
>>>
>>> can the driver get request for final/finup/digest with null req->result ?
>>> If yes (?), su
Hi Kamil,
On Fri, Dec 01, 2017 at 11:18:30AM +0100, Kamil Konieczny wrote:
> On 01.12.2017 09:11, Antoine Tenart wrote:
> > - Other drivers are doing this check (grep "if (!req->result)" or
> > "if (req->result)" to see some of them).
> > - I see at least one commit fixing the exact same issue I
On Fri, Dec 01, 2017 at 09:11:57AM +0100, Antoine Tenart wrote:
>
> I agree this should not be the case.
>
> But:
> - Other drivers are doing this check (grep "if (!req->result)" or
> "if (req->result)" to see some of them).
> - I see at least one commit fixing the exact same issue I'm facing he
On Fri, Dec 01, 2017 at 11:18:30AM +0100, Kamil Konieczny wrote:
>
> Herbert, is it possible for every init/update that areq->result can be NULL,
> and only for final/update/digit user set it to actual memory ?
> testmgr.c can check if hash update writes into areq->result and if yes,
> then test f
Hi Antoine,
On 01.12.2017 11:24, Antoine Tenart wrote:
> Hi Kamil,
>
> On Fri, Dec 01, 2017 at 11:18:30AM +0100, Kamil Konieczny wrote:
>> On 01.12.2017 09:11, Antoine Tenart wrote:
>>> - Other drivers are doing this check (grep "if (!req->result)" or
>>> "if (req->result)" to see some of them)
Hi Herbert,
On Fri, Dec 01, 2017 at 09:35:52PM +1100, Herbert Xu wrote:
> On Fri, Dec 01, 2017 at 09:11:57AM +0100, Antoine Tenart wrote:
> >
> > I agree this should not be the case.
> >
> > But:
> > - Other drivers are doing this check (grep "if (!req->result)" or
> > "if (req->result)" to see
On Fri, Dec 01, 2017 at 11:43:18AM +0100, Kamil Konieczny wrote:
> On 01.12.2017 11:24, Antoine Tenart wrote:
> >
> > Yes the last_req flag is set for the last request, so when
> > digest/finup/final are called. But no we can't copy the result into the
> > state based on this as an user might want
Hi Herbert,
On 01.12.2017 11:36, Herbert Xu wrote:
> On Fri, Dec 01, 2017 at 11:18:30AM +0100, Kamil Konieczny wrote:
>>
>> Herbert, is it possible for every init/update that areq->result can be NULL,
>> and only for final/update/digit user set it to actual memory ?
>> testmgr.c can check if hash
Add myself as co-maintainer for Samsung Security SubSystem driver.
I have added major functionality to the driver [hash acceleration],
I have access to documentation and to hardware for testing, I can
also dedicate some of my paid time for reviewing and verifying changes
to the driver.
Signed-off-
On Fri, Dec 01, 2017 at 10:01:01AM -0800, syzbot wrote:
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 30
On Tue, Nov 28, 2017 at 05:23:01AM -0800, syzbot wrote:
> ==
> BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341
> [inline]
> BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0
> crypto/sha3_generic.c:161
> Wr
On Mon, Nov 27, 2017 at 10:56:46AM -0800, syzbot wrote:
> ==
> BUG: KASAN: use-after-free in skcipher_request_set_tfm
> include/crypto/skcipher.h:499 [inline]
> BUG: KASAN: use-after-free in crypto_aead_copy_sgl
> crypto/algif_aead.c:8
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code tha
As reported by Sebastian, the way the arm64 NEON crypto code currently
keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
causing problems with RT builds, given that the skcipher walk API may
allocate and free temporary buffers it uses to present the input and
output arrays to
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code tha
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code tha
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code tha
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code tha
19 matches
Mail list logo
