On 7 September 2018 at 05:42, Herbert Xu wrote:
> On Thu, Sep 06, 2018 at 03:58:52PM -0700, Kees Cook wrote:
>>
>> @@ -437,6 +442,12 @@ static inline struct crypto_skcipher
>> *crypto_skcipher_reqtfm_check(
>> {
>> struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
>>
>> + if (
ALG_SET_KEY_TYPE requires caller to pass the key_type to be used
for AES encryption/decryption.
Sometimes the cipher key will be stored in the device's
hardware (eFuse, BBRAM etc).So,there is a need to specify the information
about the key-type to use it for Encrypt or Decrypt operations.
This pa
Hi,
On Thu, Sep 6, 2018 at 8:32 PM, Herbert Xu wrote:
> On Thu, Sep 06, 2018 at 12:33:58PM -0700, Eric Dumazet wrote:
>> On Thu, Sep 6, 2018 at 12:21 PM Olof Johansson wrote:
>> >
>> > Today these are all global shared variables per protocol, and in
>> > particular tcp_memory_allocated can get h
On Thu, Sep 06, 2018 at 09:31:33AM -0400, Jerome Glisse wrote:
> Date: Thu, 6 Sep 2018 09:31:33 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Alex Williamson , Kenneth Lee
> , Jonathan Corbet , Herbert Xu
> , "David S . Miller" ,
> Joerg Roedel , Hao Fang , Zhou Wang
> , Zaibo Xu , Phil
On Thu, Sep 06, 2018 at 03:58:52PM -0700, Kees Cook wrote:
>
> @@ -437,6 +442,12 @@ static inline struct crypto_skcipher
> *crypto_skcipher_reqtfm_check(
> {
> struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
>
> + if (req->__onstack) {
> + if (WARN_ON(crypto_skc
On Thu, Sep 06, 2018 at 12:33:58PM -0700, Eric Dumazet wrote:
> On Thu, Sep 6, 2018 at 12:21 PM Olof Johansson wrote:
> >
> > Today these are all global shared variables per protocol, and in
> > particular tcp_memory_allocated can get hot on a system with
> > large number of CPUs and a substantial
On Thu, Sep 06, 2018 at 11:36:36AM -0700, Randy Dunlap wrote:
> Date: Thu, 6 Sep 2018 11:36:36 -0700
> From: Randy Dunlap
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe
The current constraints for inline "rep xcrypt*" instructions mark ecx
as an input only. The compiler can therefore assume wrongly that ecx
holds the same value afterward, but in reality it will contain 0.
This previously led to data corruption, which was fixed around by
commit 46d8c4b28652 ("cry
In preparation to adding additional sanity checks before running an
skcipher request, this consolidates the open-coded checks into a single
function. Instead of passing both req and tfm into the new check this
just returns the tfm on success and an ERR_PTR on failure, keeping things
as clean as pos
In the quest to remove all stack VLA usage from the kernel[1], this caps
the non-ASYNC skcipher request size similar to other limits and adds a
sanity check at usage. After a review of all non-ASYNC algorithm callers
of crypto_skcipher_set_reqsize(), the largest appears to be 384:
4 struct s
This removes VLAs[1] from SKCIPHER_REQUEST_ON_STACK by making sure that
on-stack requests are being used only on non-ASYNC algorithms and that
enough space has been reserved.
v2:
- Instead of globally failing large reqsizes, limit to only non-ASYNC users
of the on-stack request.
- Remove unused
Check at use-time whether an skcipher request is on the stack. If it
is, enforce that it must be backed by a synchronous algorithm, as is
required:
https://www.redhat.com/archives/dm-devel/2018-January/msg00087.html
Co-developed-by: Ard Biesheuvel
Signed-off-by: Kees Cook
---
include/crypto/
Since the size is now fixed, there is no need to include the tfm
argument. This removes it from the definition and callers.
Suggested-by: Alexander Stein
Signed-off-by: Kees Cook
---
arch/s390/crypto/aes_s390.c| 8
arch/x86/crypto/fpu.c
On Thu, Sep 6, 2018 at 1:22 PM, Kees Cook wrote:
> On Wed, Sep 5, 2018 at 5:43 PM, Kees Cook wrote:
>> On Wed, Sep 5, 2018 at 3:49 PM, Ard Biesheuvel
>> wrote:
>>> On 5 September 2018 at 23:05, Kees Cook wrote:
On Wed, Sep 5, 2018 at 2:18 AM, Ard Biesheuvel
wrote:
> On 4 Septembe
On Wed, Sep 5, 2018 at 5:43 PM, Kees Cook wrote:
> On Wed, Sep 5, 2018 at 3:49 PM, Ard Biesheuvel
> wrote:
>> On 5 September 2018 at 23:05, Kees Cook wrote:
>>> On Wed, Sep 5, 2018 at 2:18 AM, Ard Biesheuvel
>>> wrote:
On 4 September 2018 at 20:16, Kees Cook wrote:
> In the quest to r
On Thu, Sep 6, 2018 at 12:21 PM Olof Johansson wrote:
>
> Today these are all global shared variables per protocol, and in
> particular tcp_memory_allocated can get hot on a system with
> large number of CPUs and a substantial number of connections.
>
> Moving it over to a per-cpu variable makes i
Today these are all global shared variables per protocol, and in
particular tcp_memory_allocated can get hot on a system with
large number of CPUs and a substantial number of connections.
Moving it over to a per-cpu variable makes it significantly cheaper,
and the added overhead when summing up th
On Thu, Sep 6, 2018 at 7:49 AM, Ard Biesheuvel
wrote:
> On 6 September 2018 at 15:11, Herbert Xu wrote:
>> On Thu, Sep 06, 2018 at 11:29:41AM +0200, Ard Biesheuvel wrote:
>>>
>>> Perhaps not, but it is not enforced atm.
>>>
>>> In any case, limiting the reqsize is going to break things, so that
>
Hi,
On 09/02/2018 05:51 PM, Kenneth Lee wrote:
> From: Kenneth Lee
>
> WarpDrive is a common user space accelerator framework. Its main component
> in Kernel is called sdmdev, Share Domain Mediated Device. It exposes
> the hardware capabilities to the user space via vfio-mdev. So processes in
>
On 08/20/2018 07:46 PM, Eric Biggers wrote:
> On Wed, Aug 15, 2018 at 09:35:03AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>> git tree: linux-next
>> console output: https://syzkaller
On 6 September 2018 at 15:11, Herbert Xu wrote:
> On Thu, Sep 06, 2018 at 11:29:41AM +0200, Ard Biesheuvel wrote:
>>
>> Perhaps not, but it is not enforced atm.
>>
>> In any case, limiting the reqsize is going to break things, so that
>> needs to occur based on the sync/async nature of the algo. T
On Thu, Sep 06, 2018 at 05:45:32PM +0800, Kenneth Lee wrote:
> On Tue, Sep 04, 2018 at 10:15:09AM -0600, Alex Williamson wrote:
> > Date: Tue, 4 Sep 2018 10:15:09 -0600
> > From: Alex Williamson
> > To: Jerome Glisse
> > CC: Kenneth Lee , Jonathan Corbet ,
> > Herbert Xu , "David S . Miller"
> >
On Thu, Sep 06, 2018 at 11:29:41AM +0200, Ard Biesheuvel wrote:
>
> Perhaps not, but it is not enforced atm.
>
> In any case, limiting the reqsize is going to break things, so that
> needs to occur based on the sync/async nature of the algo. That also
> means we'll corrupt the stack if we ever end
On 5 September 2018 at 21:24, Eric Biggers wrote:
> From: Eric Biggers
>
> fscrypt doesn't use the CTR mode of operation for anything, so there's
> no need to select CRYPTO_CTR. It was added by commit 71dea01ea2ed
> ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4 encryption is
> enabled"). But
On Tue, Sep 04, 2018 at 10:15:09AM -0600, Alex Williamson wrote:
> Date: Tue, 4 Sep 2018 10:15:09 -0600
> From: Alex Williamson
> To: Jerome Glisse
> CC: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Kenneth Lee
> , Hao Fang , Zhou Wang
> , Zaibo Xu , Ph
On 6 September 2018 at 10:51, Herbert Xu wrote:
> On Thu, Sep 06, 2018 at 10:11:59AM +0200, Ard Biesheuvel wrote:
>>
>> That way, we will almost certainly oops on a NULL pointer dereference
>> right after, but we at least the stack corruption.
>
> A crash is just as bad as a BUG_ON.
>
> Is this ev
On Mon, Sep 03, 2018 at 10:32:16AM +0800, Lu Baolu wrote:
> Date: Mon, 3 Sep 2018 10:32:16 +0800
> From: Lu Baolu
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe Ombreda
On Sun, Sep 02, 2018 at 07:25:12PM -0700, Randy Dunlap wrote:
> Date: Sun, 2 Sep 2018 19:25:12 -0700
> From: Randy Dunlap
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe
On Sun, Sep 02, 2018 at 07:19:03PM -0700, Randy Dunlap wrote:
> Date: Sun, 2 Sep 2018 19:19:03 -0700
> From: Randy Dunlap
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe
On Sun, Sep 02, 2018 at 07:15:07PM -0700, Randy Dunlap wrote:
> Date: Sun, 2 Sep 2018 19:15:07 -0700
> From: Randy Dunlap
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe
On Mon, Sep 03, 2018 at 10:55:57AM +0800, Lu Baolu wrote:
> Date: Mon, 3 Sep 2018 10:55:57 +0800
> From: Lu Baolu
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe Ombreda
On Thu, Sep 06, 2018 at 10:11:59AM +0200, Ard Biesheuvel wrote:
>
> That way, we will almost certainly oops on a NULL pointer dereference
> right after, but we at least the stack corruption.
A crash is just as bad as a BUG_ON.
Is this even a real problem? Do we have any users of this construct
th
On Thu, Sep 6, 2018 at 10:21 AM, Ard Biesheuvel
wrote:
>>> The skcipher implementations based on crypto IP blocks are typically
>>> asynchronous, and I wouldn't be surprised if a fair number of
>>> SKCIPHER_REQUEST_ON_STACK() users are limited to synchronous
>>> skciphers.
>>
>> According to Herb
On 6 September 2018 at 09:21, Ard Biesheuvel wrote:
> On 6 September 2018 at 06:53, Gilad Ben-Yossef wrote:
>> On Thu, Sep 6, 2018 at 1:49 AM, Ard Biesheuvel
>> wrote:
>>> On 5 September 2018 at 23:05, Kees Cook wrote:
On Wed, Sep 5, 2018 at 2:18 AM, Ard Biesheuvel
wrote:
> On 4
On Sun, Sep 02, 2018 at 07:11:12PM -0700, Randy Dunlap wrote:
> Date: Sun, 2 Sep 2018 19:11:12 -0700
> From: Randy Dunlap
> To: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Kenneth Lee , Hao
> Fang , Zhou Wang , Zaibo Xu
> , Philippe
On 6 September 2018 at 06:53, Gilad Ben-Yossef wrote:
> On Thu, Sep 6, 2018 at 1:49 AM, Ard Biesheuvel
> wrote:
>> On 5 September 2018 at 23:05, Kees Cook wrote:
>>> On Wed, Sep 5, 2018 at 2:18 AM, Ard Biesheuvel
>>> wrote:
On 4 September 2018 at 20:16, Kees Cook wrote:
> In the quest
36 matches
Mail list logo
