linux-kernel - RE: [PATCH] cifs: Remove locking in smb2_verify_signature() when calculating SMB2/SMB3 signature on receiving packets

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN8PR21MB1155DCB17C62EDCE529922ABCECC0@BN8PR21MB1155.namprd21.prod.outlook.com>
Date:   Fri, 27 Mar 2020 05:41:21 +0000
From:   Long Li <longli@...rosoft.com>
To:     Aurélien Aptel <aaptel@...e.com>,
        "longli@...uxonhyperv.com" <longli@...uxonhyperv.com>,
        Steve French <sfrench@...ba.org>,
        "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
        "samba-technical@...ts.samba.org" <samba-technical@...ts.samba.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] cifs: Remove locking in smb2_verify_signature() when
 calculating SMB2/SMB3 signature on receiving packets

>Subject: Re: [PATCH] cifs: Remove locking in smb2_verify_signature() when
>calculating SMB2/SMB3 signature on receiving packets
>
>longli@...uxonhyperv.com writes:
>> On the sending and receiving paths, CIFS uses the same cypto data
>> structures to calculate SMB2/SMB3 packet signatures. A lock on the
>> receiving path is necessary to control shared access to crypto data
>> structures. This lock degrades performance because it races with the
>sending path.
>>
>> Define separate crypto data structures for sending and receiving paths
>> and remove this lock.
>
>Something I've often wondered: why do we keep crypto state in the server
>structure instead of creating it as needed in the caller stack (thus avoiding the
>need for locks). AFAIK there's no state that need to be kept between
>signing/encrypting calls beside the access to keys. Is it that expensive to
>create/release?

My guess is that crypto_alloc_shash() is a heavy call?

>
>Cheers,
>--
>Aurélien Aptel / SUSE Labs Samba Team
>GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3 SUSE Software
>Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
>GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)