lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu,  8 Apr 2021 19:11:48 +0000
From:   Jianmin Wang <jianmin@...as.ac.cn>
To:     gregkh@...uxfoundation.org
Cc:     davem@...emloft.net, dzickus@...hat.com,
        herbert@...dor.apana.org.au, jianmin@...as.ac.cn,
        linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
        omosnace@...hat.com, smueller@...onox.de, stable@...r.kernel.org,
        steffen.klassert@...unet.com
Subject: Re: Re: [PATCH] backports: crypto user - make NETLINK_CRYPTO work 

On Mon, Apr 05, 2021 at 16:14 UTC, Greg KH wrote:
> On Mon, Apr 05, 2021 at 01:55:15PM +0000, Jianmin Wang wrote:
> > There is same problem found in linux 4.19.y as upstream commit. The 
> > changes of crypto_user_* and cryptouser.h files from upstream patch are merged into 
> > crypto/crypto_user.c for backporting.
> > 
> > Upstream commit:
> >     commit 91b05a7e7d8033a90a64f5fc0e3808db423e420a
> >     Author: Ondrej Mosnacek <omosnace@...hat.com>
> >     Date:   Tue,  9 Jul 2019 13:11:24 +0200
> > 
> >     Currently, NETLINK_CRYPTO works only in the init network namespace. It
> >     doesn't make much sense to cut it out of the other network namespaces,
> >     so do the minor plumbing work necessary to make it work in any network
> >     namespace. Code inspired by net/core/sock_diag.c.
> > 
> >     Signed-off-by: Ondrej Mosnacek <omosnace@...hat.com>
> >     Signed-off-by: default avatarHerbert Xu <herbert@...dor.apana.org.au>
> > 
> > Signed-off-by: Jianmin Wang <jianmin@...as.ac.cn>
> > ---
> >  crypto/crypto_user.c        | 37 +++++++++++++++++++++++++------------
> >  include/net/net_namespace.h |  3 +++
> >  2 files changed, 28 insertions(+), 12 deletions(-)
> 
> How does this change fit with the stable kernel rules?  It looks to be a
> new feature, if you need this, why not just use a newer kernel version?
> What is preventing you from doing that?
> 

This problem was found when we deployed new services on our container cluster, 
while the new services need to invoke libkcapi in the container environment.

We have verified that the problem doesn't exist on newer kernel version. 
However, due to many services and the cluster running on many server machines 
whose host os are long-term linux distribution with linux 4.19 kernel, it will 
cost too much to migrate them to newer os with newer kernel version. This is 
why we need to fix the problem on linux 4.19.

Only when we run docker with param --net=host, the libkcapi can be invoked 
properly. Otherwise, almost all test cases in smuellerDD/libkcapi [1] will 
failed with same error as below:

    libkcapi - Error: Netlink error: sendmsg failed
    libkcapi - Error: Netlink error: sendmsg failed
    libkcapi - Error: NETLINK_CRYPTO: cannot obtain cipher information for 
      hmac(sha1) (is required crypto_user.c patch missing? see documentation)

The cause is same as statement in upstream commit 91b05a7e, which is that 
NETLINK_CRYPTO works only in the init network namespace.

In my opinion, there are still many linux distribution running with linux 4.19 
or similar version, such as Debian 10 with linux 4.19, CentOS 8 with linux 4.18
and also their derivatives. If other people want to use libkcapi in container 
environment, they will also be bothered by this problem. [2]

So I think this patch meet two rules in stable kernel rules: It must fix a real
bug that bothers people and the upstream commit 91b05a7e exists in Linus's tree
from linux 5.4.

Thanks for your review and reply.

--
Email: Jianmin Wang <jianmin@...as.ac.cn>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ