Fixes the following sparse warning:
drivers/crypto/hisilicon/sec/sec_algs.c:396:5: warning:
symbol 'sec_send_request' was not declared. Should it be static?
Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
Signed-off-by: Wei Yongjun
---
drivers/crypto/hisilicon/sec/s
On Tue, Aug 07, 2018 at 11:10:10AM -0700, Kees Cook wrote:
>
> > Please don't add new features to the old compress interface. Any
> > new improvements should be added to scomp/acomp only. Users who
> > need new features should be converted.
>
> So, keep crypto_scomp_zbufsize() and drop crypto_co
On Tue, Aug 7, 2018 at 6:49 PM Andy Lutomirski wrote:
> I really wish we had a way to see that we use asm-generic’s copy of a header
> in all cases except where an arch opts out.
It's really not that hard to do -- symlink asm-generic to a target
called "asm" inside an otherwise empty directory,
> On Aug 7, 2018, at 4:48 PM, Jason A. Donenfeld wrote:
>
> Hey Andy,
>
>> On Tue, Aug 7, 2018 at 12:43 PM Andy Lutomirski wrote:
>> For "zinc: add simd helper", I think it should be in include/linux,
>> and include/linux/simd.h should (immediately or maybe in the future)
>> include to pick
在 2018年08月06日 星期一 08:27 下午, Pavel Machek 写道:
Hi!
WarpDrive is a common user space accelerator framework. Its main component
in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes
spimdev is really unfortunate name. It looks like it has something to do with
SPI, but
it
在 2018年08月07日 星期二 01:05 上午, Alex Williamson 写道:
On Mon, 6 Aug 2018 09:34:28 -0700
"Raj, Ashok" wrote:
On Mon, Aug 06, 2018 at 09:49:40AM -0600, Alex Williamson wrote:
On Mon, 6 Aug 2018 09:40:04 +0800
Kenneth Lee wrote:
1. It supports thousands of processes. Take zip accelerator as an ex
在 2018年08月06日 星期一 11:32 下午, Jerome Glisse 写道:
On Mon, Aug 06, 2018 at 11:12:52AM +0800, Kenneth Lee wrote:
On Fri, Aug 03, 2018 at 10:39:44AM -0400, Jerome Glisse wrote:
On Fri, Aug 03, 2018 at 11:47:21AM +0800, Kenneth Lee wrote:
On Thu, Aug 02, 2018 at 10:22:43AM -0400, Jerome Glisse wrot
On Tue, Aug 07, 2018 at 02:51:21PM -0700, Eric Biggers wrote:
> On Tue, Aug 07, 2018 at 11:21:04AM +0100, Samuel Neves wrote:
> > > The best attack on ChaCha breaks 7 rounds, and that attack requires 2^248
> > > operations.
> >
> > This number, as far as I can tell, comes from the "New features o
Hey Andy,
On Tue, Aug 7, 2018 at 12:43 PM Andy Lutomirski wrote:
> For "zinc: add simd helper", I think it should be in include/linux,
> and include/linux/simd.h should (immediately or maybe in the future)
> include to pick up arch-specific stuff. And the patch
> should get sent to linux-a...@v
Hi Ard,
On Tue, Aug 07, 2018 at 02:09:05PM +0200, Ard Biesheuvel wrote:
> On 7 August 2018 at 00:32, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Add the Poly1305 code from OpenSSL, which was written by Andy Polyakov.
> > I took the .S file from WireGuard, whose author has made the needed
On Tue, Aug 07, 2018 at 11:21:04AM +0100, Samuel Neves wrote:
> > The best attack on ChaCha breaks 7 rounds, and that attack requires 2^248
> > operations.
>
> This number, as far as I can tell, comes from the "New features of
> Latin dances" paper. There have been some minor improvements in the
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new upper bound for the stack buffer. Also adds a sanity check.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/crypto/qat/qat_comm
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by:
In the quest to remove all stack VLA usage from the kernel[1], this
exposes a new general upper bound on crypto blocksize and alignmask
(higher than for the existing cipher limits) for VLA removal,
and introduces new checks.
At present, the highest cra_alignmask in the kernel is 63. The highest
cr
In the quest to remove all stack VLA usage from the kernel[1], this
caps the skcipher request size similar to other limits and adds a sanity
check at registration. Looking at instrumented tcrypt output, the largest
is for lrw:
crypt: testing lrw(aes)
crypto_skcipher_set_reqsize: 8
In the quest to remove all stack VLA usage from the kernel[1], this
removes the VLAs in SHASH_DESC_ON_STACK (via crypto_shash_descsize())
by using the maximum allowable size (which is now more clearly captured
in a macro), along with a few other cases. Similar limits are turned into
macros as well.
In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check. For xcbc, the blocksize
must always be 16, so use that, since it's already being enforced during
instantiation.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC
v8 cover letter:
I continue to hope this can land in v4.19, but I realize that's unlikely.
It would be nice, though, if some of the "trivial" patches could get taken
(e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them.
*fingers crossed*
Series cover letter:
This is nearly t
In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since thi
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
bounds on stack usage.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
From: Ard Biesheuvel
In the quest to remove all stack VLA usage from the kernel[1], this drops
AHASH_REQUEST_ON_STACK by preallocating the ahash request area combined
with the skcipher area (which are not used at the same time).
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=
ARMv8.2 specifies special instructions for the SM3 cryptographic hash
and the SM4 symmetric cipher. While it is unlikely that a core would
implement one and not the other, we should only use SM4 instructions
if the SM4 CPU feature bit is set, and we currently check the SM3
feature bit instead. So f
On Tue, Aug 7, 2018 at 2:47 AM, Herbert Xu wrote:
> On Thu, Aug 02, 2018 at 03:51:45PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> uses the upper bounds on blocksize. Since this is always a cipher
>> blocksize, use the existing cipher max block
Hi Jeffrey,
On Mon, Aug 06, 2018 at 09:03:27PM -0400, Jeffrey Walton wrote:
> On Mon, Aug 6, 2018 at 7:04 PM, Jason A. Donenfeld wrote:
> > These are unused, undesired, and have never actually been used by
> > anybody. The original authors of this code have changed their mind about
> > its inclus
On Tue, Aug 7, 2018 at 11:54 AM, Jason A. Donenfeld wrote:
> Hey Andy, Eric, & all,
>
> I've started the work of separating this out into 16 individual
> commits, have addressed numerous other things brought up like the
> ifdef maze, and have begun rewriting (parts of) the original commit
> messag
Hey Andy, Eric, & all,
I've started the work of separating this out into 16 individual
commits, have addressed numerous other things brought up like the
ifdef maze, and have begun rewriting (parts of) the original commit
message. It's still a work in progress, and I still have some work to
do, but
On Tue, Aug 7, 2018 at 2:45 AM, Herbert Xu wrote:
> On Thu, Aug 02, 2018 at 02:51:10PM -0700, Kees Cook wrote:
>> When pstore was refactored to use the crypto compress API in:
>>
>> commit cb3bee0369bc ("pstore: Use crypto compress API")
>>
>> nearly all the pstore-specific compression routines
On Tue, Aug 07, 2018 at 03:43:12PM +0800, Yu Chen wrote:
> On Mon, Aug 06, 2018 at 06:39:58PM +0800, joeyli wrote:
> > On Mon, Aug 06, 2018 at 04:45:34PM +0800, Yu Chen wrote:
> > > Hi Pavel,
> > > On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > User s
On 7 August 2018 at 05:15, Theodore Y. Ts'o wrote:
> On Mon, Aug 06, 2018 at 08:12:38PM -0700, Eric Biggers wrote:
>> I mention this because people are naturally going to be curious about that,
>> e.g.
>> speculating that Google found a "backdoor" -- remember that we do have some
>> good
>> cryp
On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> It is possible, that caam_jr_alloc() is called before JR devices are
> probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> they are probed at later stage.
>
These drivers don't have a probe() callback.
Returning -EPROBE_DEFER in modu
On 7 August 2018 at 00:32, Eric Biggers wrote:
> From: Eric Biggers
>
> Add the Poly1305 code from OpenSSL, which was written by Andy Polyakov.
> I took the .S file from WireGuard, whose author has made the needed
> tweaks for Linux kernel integration and verified that Andy had given
> permission
> The best attack on ChaCha breaks 7 rounds, and that attack requires 2^248
> operations.
This number, as far as I can tell, comes from the "New features of
Latin dances" paper. There have been some minor improvements in the
intervening 10 years, e.g., [1, 2, 3, 4], which pull back the
complexity
On Di, 2018-08-07 at 15:38 +0800, Yu Chen wrote:
> > As STD affects the whole machine it must require root rights.
> > So I cannot see how you can talk about a session belonging
> > to a user. Please explain.
> >
>
> The case is for physical access, not the 'user' in OS.
Well, yes, but Secure Bo
On Sat, Aug 04, 2018 at 06:21:01AM +0800, kbuild test robot wrote:
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gon
On Sat, Aug 04, 2018 at 08:46:23PM +0200, Ard Biesheuvel wrote:
> Another bit of performance work on the GHASH driver: this time it is not
> the combined AES/GCM algorithm but the bare GHASH driver that gets updated.
>
> Even though ARM cores that implement the polynomical multiplication
> instruc
On Fri, Aug 03, 2018 at 01:37:50PM +0200, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not AE
On Mon, Jul 30, 2018 at 09:59:36AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable esign is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> warning: variable 'esign' set but not used [-Wunused-but-set-variable]
>
> Signed-
On Thu, Aug 02, 2018 at 03:51:45PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> uses the upper bounds on blocksize. Since this is always a cipher
> blocksize, use the existing cipher max blocksize.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-z
On Thu, Aug 02, 2018 at 02:51:10PM -0700, Kees Cook wrote:
> When pstore was refactored to use the crypto compress API in:
>
> commit cb3bee0369bc ("pstore: Use crypto compress API")
>
> nearly all the pstore-specific compression routines were replaced with
> the existing crypto compression API
Hi,
I'm resending patch series, as I forgot to CC linux-crypto list.
This patch series fixes/improves CAAM JR dependent drivers initialization.
So far successful initialization depended on link and device-tree nodes
order. These changes make sure all drivers that use JRs (i.e. call
caam_jr_alloc()
There is a race condition, when driver is not initialized
yet (jr_driver_init() was not called yet), but another kernel
code calls caam_jr_alloc(). This results in warnings about
uninitialized lock and NULL pointer dereference error.
Fix that by statically initializing global driver data, so
caam_
It is possible, that caam_jr_alloc() is called before JR devices are
probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
they are probed at later stage.
Signed-off-by: Marcin Niestroj
---
drivers/crypto/caam/caamalg.c| 3 +++
drivers/crypto/caam/caamalg_qi.c | 3 +++
drivers/
On Tue, Aug 7, 2018 at 3:33 PM Yu Chen wrote:
>
> On Mon, Aug 06, 2018 at 12:20:20PM +0200, Oliver Neukum wrote:
> > On Mo, 2018-08-06 at 15:57 +0800, Yu Chen wrote:
> > > Hi Oliver,
> > > On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> > > > On Di, 2018-07-24 at 00:23 +0800, Yu C
On Mon, Aug 06, 2018 at 06:39:58PM +0800, joeyli wrote:
> On Mon, Aug 06, 2018 at 04:45:34PM +0800, Yu Chen wrote:
> > Hi Pavel,
> > On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > User space doesn't need to involve. The EFI root key is generated by
> > > >
On Mon, Aug 06, 2018 at 12:20:20PM +0200, Oliver Neukum wrote:
> On Mo, 2018-08-06 at 15:57 +0800, Yu Chen wrote:
> > Hi Oliver,
> > On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> > > On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> > > >
> > > > Good point, we once tried to ge
45 matches
Mail list logo
