* Josh Poimboeuf wrote:
> On Mon, Jun 25, 2018 at 09:24:38AM +0200, Ingo Molnar wrote:
> >
> > * Alexey Dobriyan wrote:
> >
> > > On Sun, Jun 24, 2018 at 09:11:05AM +0200, Ingo Molnar wrote:
> > > > > Add explicit RETs to the tail calls of AEGIS and MORUS crypto
> > > > > algorithms
> > > >
On Mon, Jun 25, 2018 at 3:56 PM, Eric Biggers wrote:
> On Mon, Jun 25, 2018 at 02:10:25PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this caps
>> the ahash request size similar to the other limits and adds a sanity
>> check at registration. Unfortunat
On Mon, Jun 25, 2018 at 02:10:25PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this caps
> the ahash request size similar to the other limits and adds a sanity
> check at registration. Unfortunately, these reqsizes can be huge. Looking
> at all callers o
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/crypto/aegis128-aesni-asm.S
On Mon, 2018-06-25 at 14:32 -0700, Kees Cook wrote:
> On Mon, Jun 25, 2018 at 2:23 PM, Joe Perches wrote:
> > On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
> > > In the quest to remove all stack VLA usage from the kernel[1], this uses
> > > the maximum blocksize and adds a sanity check. For
On Mon, Jun 25, 2018 at 2:23 PM, Joe Perches wrote:
> On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
>> 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 i
On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
> 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.
Is it
Hi,
v2:
- use 512 instead of PAGE_SIZE / 8 to avoid bloat on large-page archs.
- swtich xcbc to "16" max universally.
- fix typo in bounds check for dm buffer size.
- examine actual reqsizes for skcipher and ahash instead of guessing.
- improve names and comments for alg maxes
This is nearly the
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). Similar limits are turned into macros as well.
[1]
https://lkml.kernel.org
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new SHASH_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
Cc: Alasdair Kergon
Cc: Mike
In the quest to remove all stack VLA usage from the kernel[1], this
uses the newly defined max digest size macro. Also adds a sanity-check
at use-time.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: dm-d
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
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 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 upper bound for the stack buffer. Also adds a sanity check.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Giovanni Cabiddu
Cc: Herbert Xu
Cc: "David S. Miller
In the quest to remove all stack VLA usage from the kernel[1], this caps
the ahash request size similar to the other limits and adds a sanity
check at registration. Unfortunately, these reqsizes can be huge. Looking
at all callers of crypto_ahash_set_reqsize(), the largest appears to be
664 bytes,
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. In a manual review of the callers of
crypto_skcipher_set_reqsize(), the largest was 384:
4 sun4i_cipher_req_ctx
6 safexcel
In the quest to remove all stack VLA usage from the kernel[1], this
introduces max size macros for ahash, as already done for shash, and
adjust the crypto user to max state size.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Herbert Xu
Cc:
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
Cc: Herbert Xu
Hi Rob,
On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote:
> Looks like imx51 should be a fallback and you can drop the driver
> change.
I thought about that too.
If I do like this in imx51.dtsi:
compatible = "fsl,imx51-sahara", "fsl,imx53-sahara";
Then the driver works just fine.
I was no
On Fri, Jun 22, 2018 at 03:45:28PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> i.MX51 and i.MX53 share the same sahara IP block version, so add
> i.MX51 in the list of supported SoCs.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fix typo in commit log "i.MX51 and i.M
On Tue, Jun 19, 2018 at 03:24:29PM +0530, Vinod Koul wrote:
> Later qcom chips support v2 of the prng, so add new compatible
> qcom,prng-v2 for this.
>
> Signed-off-by: Vinod Koul
> ---
>
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Documentation/devicetree/bindings/rng/qcom,prng.txt |
Hi David,
On Fri, Jun 08, 2018 at 04:37:58PM +0100, David Howells wrote:
> Eric Biggers wrote:
>
> > Commit 383203eff718 ("dh key: get rid of stack allocated array") changed
> > kdf_ctr() to assume that the length of key material to derive is a
> > multiple of the digest size. The length was su
On Mon, Jun 25, 2018 at 02:59:58PM +0200, Christophe LEROY wrote:
>
>
> Le 25/06/2018 à 14:45, Stafford Horne a écrit :
> > As of GCC 9.0.0 the build is reporting warnings like:
> >
> > crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
> > crypto/ablkcipher.c:374:2: warning:
Le 25/06/2018 à 15:24, Stafford Horne a écrit :
On Mon, Jun 25, 2018 at 02:57:13PM +0200, Christophe LEROY wrote:
Le 25/06/2018 à 14:45, Stafford Horne a écrit :
When compiling with GCC 9.0.0 I am seeing the following warning:
In function ‘fill_kobj_path’,
inlined from ‘kobj
On Mon, Jun 25, 2018 at 02:57:13PM +0200, Christophe LEROY wrote:
>
>
> Le 25/06/2018 à 14:45, Stafford Horne a écrit :
> > When compiling with GCC 9.0.0 I am seeing the following warning:
> >
> > In function ‘fill_kobj_path’,
> > inlined from ‘kobject_get_path’ at lib/kobject.c:155:2:
On Mon, Jun 25, 2018 at 09:24:38AM +0200, Ingo Molnar wrote:
>
> * Alexey Dobriyan wrote:
>
> > On Sun, Jun 24, 2018 at 09:11:05AM +0200, Ingo Molnar wrote:
> > > > Add explicit RETs to the tail calls of AEGIS and MORUS crypto algorithms
> > > > otherwise they run into INT3 padding due to
> > >
Le 25/06/2018 à 14:45, Stafford Horne a écrit :
As of GCC 9.0.0 the build is reporting warnings like:
crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals
destination size [-Wstringop-truncation]
Le 25/06/2018 à 14:45, Stafford Horne a écrit :
When compiling with GCC 9.0.0 I am seeing the following warning:
In function ‘fill_kobj_path’,
inlined from ‘kobject_get_path’ at lib/kobject.c:155:2:
lib/kobject.c:128:3: warning: ‘strncpy’ output truncated before
terminating
When compiling with GCC 9.0.0 I am seeing the following warning:
In function ‘fill_kobj_path’,
inlined from ‘kobject_get_path’ at lib/kobject.c:155:2:
lib/kobject.c:128:3: warning: ‘strncpy’ output truncated before terminating
nul copying as many bytes from a string as its length
As of GCC 9.0.0 the build is reporting warnings like:
crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals
destination size [-Wstringop-truncation]
strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?:
Hello,
When compiling OpenRISC kernels with our new toolchain based on GCC 9.0.0 I am
seeing various -Wstringop-truncation warnings. There might be more as I am not
compiling all drivers/modules yet, if someone thinks thats helpful let me know.
I discussed this with Greg KH at the OSS Summit Jap
According to SP800-56A section 5.6.2.1, the public key to be processed
for the ECDH operation shall be checked for appropriateness. When the
public key is considered to be an ephemeral key, the partial validation
test as defined in SP800-56A section 5.6.2.3.4 can be applied.
The partial verificati
On Thu, 2018-06-21 at 14:55 +0200, Ingo Molnar wrote:
> Just some quick feedback: these are core kernel functionality and should be
> in
> arch/x86/, not in drivers/platform/.
We have in core what is used by both KVM and the driver right now (EPC
management, SGX detection and some other bits). Th
* Alexey Dobriyan wrote:
> On Sun, Jun 24, 2018 at 09:11:05AM +0200, Ingo Molnar wrote:
> > > Add explicit RETs to the tail calls of AEGIS and MORUS crypto algorithms
> > > otherwise they run into INT3 padding due to
> > >
> > > 51bad67ffbce ("x86/asm: Pad assembly functions with INT3 instru
35 matches
Mail list logo
