Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp189940rwd; Mon, 15 May 2023 22:53:02 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ65mQMjfE4shHfuhWJ+gzqpFSM8VdP0UMZ1e8KhZ0PwK8BMOMPAbneK/xYlHGM7oHrk0M+6 X-Received: by 2002:a17:902:a5ca:b0:1ac:797b:8cf6 with SMTP id t10-20020a170902a5ca00b001ac797b8cf6mr25637668plq.69.1684216382605; Mon, 15 May 2023 22:53:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684216382; cv=none; d=google.com; s=arc-20160816; b=ck8761eWY7QhksPGswTSMSDuYiF3VavtraoS3+a3be550s18pbFsbv5Az42/P/SOBo PrnLj/FNvyZJxOPyAd79qTY7fcaFV06D0HbFNyHCQeitu5WyO23BvYbWyZViir9Umhq9 XZoiKvcq+V0tf2vBtQuQQQjRLDSfD7Ik1Jmo01rkKFALF88mCrEBnPsNcZP/BAHu5kFU VyKyt4eWJNCLgUZLT6HVBGd9LsMdXcfpnAk2+qCrRMhWgruD7vJg0LBxUdHXuKU9SdOi x30ZqqmTOXvZ/eVbEEHXV8CCW9xsy2ZgxqzCdqfIjnQVICi7k170m3n4+xxJkaewTz3k aK8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4yOvfHYZWuSo2ttkLQvhZ3XPzOQzXhV87Jomd0oypkQ=; b=h/X4WyszxPUprCFe0E33qmpA55QPHsU/wj4AosqhwSvT+681KN2B7Mo/B9AIMpYAMp qEchk2yRfOm4qmwWMQk4GW65hn2pZkOuwLmtwlCC3vgn39v0fElAX1ph8kiDj1twLEV8 7FwJciki/hyhXZah/1G9b/xQSJEu4w4XGkh8+thB3HHq7YVxWJ9IGdqKcB7t4kLyCFQJ iUOaimJ9USJM8k0rh5AgwqCBgAWvVaOeAbal8rbm9j1CEnT7IaNTOJXa8HzyNe/je5BL AaEFsHIq9BBO25IDqy3ulda7y24lzEHy63iUglXHegoAVqutWUvqP3VQYbyf7jViLsLv vWxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qRgroj2v; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j8-20020a170903024800b001aad6ad4ebcsi829483plh.150.2023.05.15.22.52.47; Mon, 15 May 2023 22:53:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qRgroj2v; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229978AbjEPFwY (ORCPT + 99 others); Tue, 16 May 2023 01:52:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229572AbjEPFwX (ORCPT ); Tue, 16 May 2023 01:52:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6794740E1; Mon, 15 May 2023 22:52:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 041ED62E86; Tue, 16 May 2023 05:52:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A649C433EF; Tue, 16 May 2023 05:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684216341; bh=UnnfSoH2Sog9IytTw4FHR+TpDmR01YMPhEE6qSYNrPo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qRgroj2v2j30UkZE/IdvIx7y4qOvg4zGQutz4YlyomWWWtOTD+9jg5OLkKW4gBsdz 8CRaQByqbQQTsxSioc5ywuaDeXO+biQAPqJRokKoz3Lb44gykAM0l6f2N+ktTCpGB/ u1314ylalzvx9n1XCWv/pTrS9n81y0t/77U9nCIdo1t6zW1RJNP4UVe1S2sX+4U5Sb JhrNTsreJV+HSjMwX2wG0++uPNyteN9Qqd+JL76R8EzSD4ko4DPyJbC70qgdFT5Y+R hfgcxoERDQ5C5w1mbqD7jzGl+2POjJh4nB+f2lJaMbNk8+SKD+nzL5jw0FhWlJFzdB qn2WrrvkGakxg== Date: Mon, 15 May 2023 22:52:19 -0700 From: Eric Biggers To: FUJITA Tomonori Cc: rust-for-linux@vger.kernel.org, netdev@vger.kernel.org, linux-crypto@vger.kernel.org, FUJITA Tomonori Subject: Re: [PATCH 1/2] rust: add synchronous message digest support Message-ID: <20230516055219.GC2704@sol.localdomain> References: <20230515043353.2324288-1-tomo@exabit.dev> <010101881db037b4-c8c941a9-c482-4759-9c07-b8bf645d96ed-000000@us-west-2.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010101881db037b4-c8c941a9-c482-4759-9c07-b8bf645d96ed-000000@us-west-2.amazonses.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Fujita, On Mon, May 15, 2023 at 04:34:27AM +0000, FUJITA Tomonori wrote: > diff --git a/rust/helpers.c b/rust/helpers.c > index 81e80261d597..03c131b1ca38 100644 > --- a/rust/helpers.c > +++ b/rust/helpers.c > @@ -18,6 +18,7 @@ > * accidentally exposed. > */ > > +#include > #include > #include > #include > @@ -27,6 +28,29 @@ > #include > #include > > +void rust_helper_crypto_free_shash(struct crypto_shash *tfm) > +{ > + crypto_free_shash(tfm); > +} > +EXPORT_SYMBOL_GPL(rust_helper_crypto_free_shash); Shouldn't this code be compiled only when the crypto API is available? > +impl<'a> ShashDesc<'a> { > + /// Creates a [`ShashDesc`] object for a request data structure for message digest. > + pub fn new(tfm: &'a Shash) -> Result { > + // SAFETY: The type invariant guarantees that the pointer is valid. > + let size = core::mem::size_of::() > + + unsafe { bindings::crypto_shash_descsize(tfm.0) } as usize; > + let layout = Layout::from_size_align(size, 2)?; > + let ptr = unsafe { alloc(layout) } as *mut bindings::shash_desc; > + let mut desc = ShashDesc { ptr, tfm, size }; > + // SAFETY: The `desc.tfm` is non-null and valid for the lifetime of this object. > + unsafe { (*desc.ptr).tfm = desc.tfm.0 }; > + Ok(desc) > + } > + > + /// (Re)initializes message digest. > + pub fn init(&mut self) -> Result { > + // SAFETY: The type invariant guarantees that the pointer is valid. > + to_result(unsafe { bindings::crypto_shash_init(self.ptr) }) > + } > + > + /// Adds data to message digest for processing. > + pub fn update(&mut self, data: &[u8]) -> Result { > + // SAFETY: The type invariant guarantees that the pointer is valid. > + to_result(unsafe { > + bindings::crypto_shash_update(self.ptr, data.as_ptr(), data.len() as u32) > + }) > + } > + > + /// Calculates message digest. > + pub fn finalize(&mut self, output: &mut [u8]) -> Result { > + // SAFETY: The type invariant guarantees that the pointer is valid. > + to_result(unsafe { bindings::crypto_shash_final(self.ptr, output.as_mut_ptr()) }) > + } This doesn't enforce that init() is called before update() or finalize(). I think that needs to be checked in the Rust code, since the C code doesn't have defined behavior in that case. - Eric