netdev - RE: [net-next v2 1/4] tipc: optimize key switching time and logic

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:   Wed, 2 Sep 2020 06:16:44 +0000
From:   Tuong Tong Lien <tuong.t.lien@...tech.com.au>
To:     David Miller <davem@...emloft.net>
CC:     "jmaloy@...hat.com" <jmaloy@...hat.com>,
        "maloy@...jonn.com" <maloy@...jonn.com>,
        "ying.xue@...driver.com" <ying.xue@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tipc-discussion@...ts.sourceforge.net" 
        <tipc-discussion@...ts.sourceforge.net>
Subject: RE: [net-next v2 1/4] tipc: optimize key switching time and logic



> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Wednesday, September 2, 2020 5:10 AM
> To: Tuong Tong Lien <tuong.t.lien@...tech.com.au>
> Cc: jmaloy@...hat.com; maloy@...jonn.com; ying.xue@...driver.com; netdev@...r.kernel.org; tipc-
> discussion@...ts.sourceforge.net
> Subject: Re: [net-next v2 1/4] tipc: optimize key switching time and logic
> 
> From: Tuong Lien <tuong.t.lien@...tech.com.au>
> Date: Mon, 31 Aug 2020 15:38:14 +0700
> 
> > We reduce the lasting time for a pending TX key to be active as well as
> > for a passive RX key to be freed which generally helps speed up the key
> > switching. It is not expected to be too fast but should not be too slow
> > either. Also the key handling logic is simplified that a pending RX key
> > will be removed automatically if it is found not working after a number
> > of times; the probing for a pending TX key is now carried on a specific
> > message user ('LINK_PROTOCOL' or 'LINK_CONFIG') which is more efficient
> > than using a timer on broadcast messages, the timer is reserved for use
> > later as needed.
> >
> > The kernel logs or 'pr***()' are now made as clear as possible to user.
> > Some prints are added, removed or changed to the debug-level. The
> > 'TIPC_CRYPTO_DEBUG' definition is removed, and the 'pr_debug()' is used
> > instead which will be much helpful in runtime.
> >
> > Besides we also optimize the code in some other places as a preparation
> > for later commits.
> >
> > This commit does not change the en/decryption functionalities.
> >
> > Acked-by: Jon Maloy <jmaloy@...hat.com>
> > Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>
> 
> Random log messages in response to user config requests are
> inappropriate especially with netlink.
> 
> Report such informational responses to errors using the
> genl_info->extack instead, as is standard practice across
> the entire kernel.
> 
> Please remove all kernel log messages that get emitted due to
> netlink operations and use extack notifications instead.
Yes, the netlink extack message is fine but the fact is that we currently do not obtain such message from the user space tool (i.e. iproute2/tipc). So, if really needed, we will have to update the tool as well... For now, I will remove all the message logs as it is fine enough with the return code.

> 
> I also disagree with the commit message stating:
> 
> 	This commit does not change the en/decryption functionalities.
> 
> You are changing timer lengths and other aspects of crypto behavior,
> so the patch is in fact changing things.
Ok, will remove this statement (this patch was merged from two different ones, so indeed made some changes).
Thanks for the comments!

BR/Tuong