Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1136796ybl; Tue, 3 Dec 2019 02:18:08 -0800 (PST) X-Google-Smtp-Source: APXvYqwLI8WJLX9A5B85IP8QH5gJeeWWqIcpTnHyE6yxYSgtY/0oz8SelG7/KU5ELbAliHcCiRth X-Received: by 2002:a05:6830:22e6:: with SMTP id t6mr2720943otc.244.1575368288252; Tue, 03 Dec 2019 02:18:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575368288; cv=none; d=google.com; s=arc-20160816; b=ZHakXHeMR/Wgd6CSFwUItMldYHlj/5VlcJ0LfHkWyk9F1RIT1FnBpBSwMW0C6Q6OSU PnknbdOTPtcn8paCa/nEQK/o9HDZ4PdSteWB+ZJpPaLTDUvta8lhUWsAfau6WfLi+Io8 Ebnb1r1Y6huei3zuvPZDPAaZB6NwyI+Vr/vTNbctnY/g7SbXBwt89yG3uAHzfW0GgUeU FunNeoGxBZlBgNxyOu/YPtpD41Pq3ACaYUnbuLAfXk7kxGeid3IZQVo/dbscZbLrN+Pb IctL4hbe4zE0H+UOh/ns++2AbaSxxMyMIzIIcu6G3IILjNXj8XOdDgGszs2JpmbQgqGJ IO5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=BMw07fQO2tL3RoykOWfqWZ2DUgxWWT/WJxWu+/44aB4=; b=coZu1LyzbZTQxtP3RubDhFtnhsGZ8tsLoNpg5Gy6KGkkbKIFKGPfMe3cIc+yY0CFcl kxBqfM3WBRFzdHZWCbQgo9ygvp2AT34SvA1Q2tOjALWUQoz/iUfrMekyf1uplZLQXrcb lfofkdU/50HE4PkZHqcH9TNh4klblTOO4vhn5SBxgedgFAc3gmelVhQnNVLGPDs53dxz arodEN7Fs8kwf3RD0YLyk0IztIXo6qK3E11MKssyYgM/lp9SPRaXhRB8jBU/D8z2UyOW aeMyIHaWAIK47YzY1xWQcfFWKxr0XkYBqp7y8C7zzdF0mm1rE2x65f2JcXJiTPFwzC97 DLfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kMScm8GS; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 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 vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v24si1022728oiv.45.2019.12.03.02.17.48; Tue, 03 Dec 2019 02:18:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kMScm8GS; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 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 S1725907AbfLCKRl (ORCPT + 99 others); Tue, 3 Dec 2019 05:17:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:34238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbfLCKRl (ORCPT ); Tue, 3 Dec 2019 05:17:41 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CBC562068E; Tue, 3 Dec 2019 10:17:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575368260; bh=5ySN3e5aUDRbhiQLCPyxs/vWIneLIy4KAn4LJwCq6Qs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kMScm8GSzW4KeDWfSNSKzpGeRbVVCFvwkHxu3o+HncYmc1ZMD9uM8+flajxYG3OSj /3ciRNYMo3BiZw+E7eMtEjiYd7+acvkY5XsvqH5JshHzGPG8kNDM9bW1JHSNuNlDOg pVuRor6iCytI5GH4UIuH6jiB6DLUtCW0mKX2yae8= Date: Tue, 3 Dec 2019 10:17:20 +0000 From: Will Deacon To: Marc Zyngier Cc: Ard Biesheuvel , Neal Liu , Catalin Marinas , Lars Persson , Mark Rutland , DTML , Herbert Xu , wsd_upstream , Sean Wang , Linux Kernel Mailing List , Rob Herring , Crystal Guo =?utf-8?B?KOmDreaZtik=?= , "linux-crypto@vger.kernel.org" , Matt Mackall , Matthias Brugger , "linux-mediatek@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Message-ID: <20191203101720.GD6815@willie-the-truck> References: <1574864578-467-1-git-send-email-neal.liu@mediatek.com> <1574864578-467-4-git-send-email-neal.liu@mediatek.com> <1575027046.24848.4.camel@mtkswgap22> <20191202191146.79e6368c@why> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191202191146.79e6368c@why> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Dec 02, 2019 at 07:11:46PM +0000, Marc Zyngier wrote: > On Mon, 2 Dec 2019 16:12:09 +0000 > Ard Biesheuvel wrote: > > > (adding some more arm64 folks) > > > > On Fri, 29 Nov 2019 at 11:30, Neal Liu wrote: > > > > > > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote: > > > > Hi Neal, > > > > > > > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu wrote: > > > > > > > > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like > > > > > entropy sources is not accessible from normal world (linux) and > > > > > rather accessible from secure world (ATF/TEE) only. This driver aims > > > > > to provide a generic interface to ATF rng service. > > > > > > > > > > > > > I am working on several SoCs that also will need this kind of driver > > > > to get entropy from Arm trusted firmware. > > > > If you intend to make this a generic interface, please clean up the > > > > references to MediaTek and give it a more generic name. For example > > > > "Arm Trusted Firmware random number driver". > > > > > > > > It will also be helpful if the SMC call number is configurable. > > > > > > > > - Lars > > > > > > Yes, I'm trying to make this to a generic interface. I'll try to make > > > HW/platform related dependency to be configurable and let it more > > > generic. > > > Thanks for your suggestion. > > > > > > > I don't think it makes sense for each arm64 platform to expose an > > entropy source via SMC calls in a slightly different way, and model it > > as a h/w driver. Instead, we should try to standardize this, and > > perhaps expose it via the architectural helpers that already exist > > (get_random_seed_long() and friends), so they get plugged into the > > kernel random pool driver directly. > > Absolutely. I'd love to see a standard, ARM-specified, virtualizable > RNG that is abstracted from the HW. Same here. I hacked up some initial code for doing this with KVM [1], but I'd much rather it was part of a standard service specification so that we could use the same interface for talking to the firmware and the hypervisor. Will [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=kvm/hvc