On 16-07-18, 11:20, Vinod Koul wrote:
> This series removes the hwrng qcom driver and replaces it with crypto qcom
> driver and then adds support for Execution Environment (EE) found in v2
> version of the hardware and ACPI support for these
Stephan, Herbert
Any chance this could make it for 4.19
On Mon, Jul 23, 2018 at 12:11:12PM -0400, Jeffrey Walton wrote:
>
> I believe Stephan Mueller wrote up the weakness a couple of years ago.
> He's the one who explained the interactions to me. Mueller was even
> cited at https://github.com/systemd/systemd/issues/4167.
Stephan had a lot of complain
From: Eric Biggers
Like the skcipher_walk and blkcipher_walk cases:
scatterwalk_done() is only meant to be called after a nonzero number of
bytes have been processed, since scatterwalk_pagedone() will flush the
dcache of the *previous* page. But in the error case of
ablkcipher_walk_done(), e.g.
From: Eric Biggers
Like the skcipher_walk case:
scatterwalk_done() is only meant to be called after a nonzero number of
bytes have been processed, since scatterwalk_pagedone() will flush the
dcache of the *previous* page. But in the error case of
blkcipher_walk_done(), e.g. if the input wasn't
From: Eric Biggers
scatterwalk_done() is only meant to be called after a nonzero number of
bytes have been processed, since scatterwalk_pagedone() will flush the
dcache of the *previous* page. But in the error case of
skcipher_walk_done(), e.g. if the input wasn't an integer number of
blocks, sc
From: Eric Biggers
This series fixes the bug reported by Liu Chao (found using syzkaller)
where a crash occurs in scatterwalk_pagedone() on architectures such as
arm and arm64 that implement flush_dcache_page(), due to an invalid page
pointer when walk->offset == 0. This series attempts to addre
From: Eric Biggers
Setting 'walk->nbytes = walk->total' in skcipher_walk_first() doesn't
make sense because actually walk->nbytes needs to be set to the length
of the first step in the walk, which may be less than walk->total. This
is done by skcipher_walk_next() which is called immediately afte
From: Eric Biggers
scatterwalk_samebuf() is never used. Remove it.
Signed-off-by: Eric Biggers
---
include/crypto/scatterwalk.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index eac72840a7d2..a66c127a20ed 100644
--- a/i
From: Eric Biggers
All callers pass chain=0 to scatterwalk_crypto_chain().
Remove this unneeded parameter.
Signed-off-by: Eric Biggers
---
crypto/lrw.c | 4 ++--
crypto/scatterwalk.c | 2 +-
crypto/xts.c | 4 ++--
include/crypto/scatterwalk.h | 8 +-
From: Eric Biggers
The ALIGN() macro needs to be passed the alignment, not the alignmask
(which is the alignment minus 1).
Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
Cc: # v4.10+
Signed-off-by: Eric Biggers
---
crypto/skcipher.c | 2 +-
1 file changed, 1 insertion(
On 23 July 2018 at 16:16, Theodore Y. Ts'o wrote:
> On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
>>
>> Did that, no change. Ran strace from the bootscript, confirmed that
>> only /dev/urandom was being used, and that it seemed to be blocking.
>
> Nope, /dev/urandom still doesn't bl
Hello,
On Mon, Jul 23, 2018 at 02:22:27PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > 2. Ideally kernel memory should be encrypted by the
> > > >kernel itself. We have uswsusp to support user
> > > >space hibernation, however doing the encryption
> > > >in kernel space has more advantag
Hi,
On Mon, Jul 23, 2018 at 01:42:36PM +0200, Oliver Neukum wrote:
> On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote:
> > Hi!
>
> Hello,
>
> > > Let me paste the log here:
> > >
> > > 1. (This is not to compare with uswsusp but other
> > > tools) One advantage is: Users do not have to
>
On Mon, Jul 23, 2018 at 11:16 AM, Theodore Y. Ts'o wrote:
> On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
>> ...
> One of the reasons why I didn't see the problem when I was developing
> the remediation patch for CVE-2018-1108 is because I run Debian
> testing, which doesn't have thi
This accelerator is found inside hisilicon hip06 and hip07 SoCs.
Each instance provides a number of queues which feed a different number of
backend acceleration units.
The queues are operating in an out of order mode in the interests of
throughput. The silicon does not do tracking of dependencies
The driver provides in kernel support for the Hisilicon SEC accelerator
found in the hip06 and hip07 SoCs. There are 4 such units on the D05
board for which an appropriate DT binding has been provided. ACPI also
works with an appropriate UEFI build.
The hardware does not update the IV in chainin
Enable all 4 SEC units available on d05 boards.
Signed-off-by: Jonathan Cameron
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 284 +++
1 file changed, 284 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
The hip06 and hip07 SoCs contain a number of these crypto units which
accelerate AES and DES operations.
Signed-off-by: Jonathan Cameron
---
.../bindings/crypto/hisilicon,hip07-sec.txt| 67 ++
1 file changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bin
On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
> Ted,
>
> last week you proposed an rfc patch to gather entropy from the CPU's
> hwrng, and I was pleased - until I discovered one of my stalling
> desktop machines does not have a hwrng. At that point I thought that
> the problem was o
Hi Gilad,
On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef wrote:
> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef wrote:
> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> > wrote:
> >> CC linux-crypto for the crash log.
> >>
> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef
>
On Fri, 20 Jul 2018 20:17:22 +0200
Stephan Müller wrote:
> Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm,
> > + const u8 *key, unsigned int
On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef wrote:
> On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> wrote:
>> Hi Gilad,
>>
>> CC linux-crypto for the crash log.
>>
>> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote:
>>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
>>>
Avoid RCU stalls in the case of non-preemptible kernel and lengthy
speed tests by rescheduling when advancing from one block size
to another.
Signed-off-by: Horia Geantă
---
crypto/tcrypt.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a
Hi!
> > > 2. Ideally kernel memory should be encrypted by the
> > >kernel itself. We have uswsusp to support user
> > >space hibernation, however doing the encryption
> > >in kernel space has more advantages:
> > >2.1 Not having to transfer plain text kernel memory to
> > >
On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote:
> Hi!
Hello,
> > Let me paste the log here:
> >
> > 1. (This is not to compare with uswsusp but other
> > tools) One advantage is: Users do not have to
> > encrypt the whole swap partition as other tools.
>
> Well.. encrypting the pa
On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
wrote:
> Hi Gilad,
>
> CC linux-crypto for the crash log.
>
> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote:
>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
>> wrote:
>> > I've noticed CCREE is used with a LUKS-formatted disk,
Hi Gilad,
CC linux-crypto for the crash log.
On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote:
> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> wrote:
> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
> > performance benchmarks. The disk is an old 160
__virtio_crypto_ablkcipher_do_req() is never called in atomic context.
__virtio_crypto_ablkcipher_do_req() is only called by
virtio_crypto_ablkcipher_crypt_req(), which is only called by
virtcrypto_find_vqs() that is never called in atomic context.
__virtio_crypto_ablkcipher_do_req() calls kzal
adf_dev_aer_schedule_reset() is never called in atomic context, as it
calls wait_for_completion_timeout().
adf_dev_aer_schedule_reset() calls kzalloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written b
crypto_alloc_context() is only called by nitrox_skcipher_init(), which is
never called in atomic context.
crypto_alloc_context() calls dma_pool_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written b
Hi Olof,
On Sat, Jul 21, 2018 at 02:35:01PM -0700, Olof Johansson wrote:
> On Thu, Jun 28, 2018 at 8:15 AM, Antoine Tenart
> wrote:
> > New compatibles are now supported by the Inside Secure SafeXcel driver.
> > As they are more specific than the old ones, they should be used
> > whenever possibl
On 2018/7/23 14:21, Herbert Xu wrote:
On Mon, Jul 23, 2018 at 10:39:40AM +0800, Jia-Ju Bai wrote:
My tool DCNS reports three unnecessary usages of GFP_ATOMIC in
crypto/ablkcipher.c:
crypto/ablkcipher.c, 162: kmalloc(GFP_ATOMIC) in ablkcipher_next_slow
crypto/ablkcipher.c, 199: kmalloc(GFP_ATO
32 matches
Mail list logo
