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  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

Powered by blists - more mailing lists