Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp528149pxb; Thu, 5 Nov 2020 06:32:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwhktIp5HW2PD1lD8L3APTgEdsxCosM+gUAkK3YjbUx7+WIB5brwVcAGj3a1qTqakPLEpd X-Received: by 2002:a50:8745:: with SMTP id 5mr2779987edv.49.1604586746775; Thu, 05 Nov 2020 06:32:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604586746; cv=none; d=google.com; s=arc-20160816; b=km0bGlnFhZJlnE5kbVprdPNiLQKXzPjCtNjajZwCwVJ1zLHQy98Yi4lN2xsd3TXucY FRnSCVncm6kVYu7XTrD2Om0LnbtDOSTvV+U1l1Afurs6zrw9ijiNrGLEZLJ3cmyVfO8A LPN8ynqjqoKVfsgTpe9JtMVp6ocGKx5X5QuFOkAvhv6FQ1U01doYk4xXBjoMB6ezxm0G JosBhokUfAAb8ECe/QvaeIUKANjKHzaiiFpTcZQDpdJIlrEwOOK49EXqWvPz0aGIHSD3 Ly7Uf6F8YHkUgc5Qyz9T0MDQZPelT8UitoR2e5qe0Sb+zc+AwcnxQNxEZ3aLqfslbokY FYMQ== 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; bh=QeE9sw5wNB+/wCwHRVQi5l3fa/AEfPk0v2VN578E2v4=; b=QaBnC4OdbImwSshaCLzCWpWhA7K6HhXkRMErUlNi+xoYFJsIMP3rOWakyXENIhJX7P mtzhTv0ILqoqNya0kseELAP4Xc2q11uqV77ZYo08j9c/93+jqV5DGfocsq/EtYb0PrDw HsvJks/g6XWqfuyufJkhwfDEv3UxhfaEq+76wT0z4WOFmjU82XzE03RR6IeXdRQOMqTg euhrZ/IyXrtwKJSlOREvKhCWgxaCF7Sbv8zNvyWGIYNOXwAoEIBhsBn3iOCmcMInNEOK ONtR6cujVT3sg5VnD/NLsGSnG5x8ugXwNHHcF9zYAVZ3ppkYvMv3KXibA3Wc8kyiqXpC fF6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si1313454edq.312.2020.11.05.06.32.02; Thu, 05 Nov 2020 06:32:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731105AbgKEOab (ORCPT + 99 others); Thu, 5 Nov 2020 09:30:31 -0500 Received: from foss.arm.com ([217.140.110.172]:34116 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726874AbgKEOab (ORCPT ); Thu, 5 Nov 2020 09:30:31 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9462114BF; Thu, 5 Nov 2020 06:30:30 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.58.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9D2363F719; Thu, 5 Nov 2020 06:30:26 -0800 (PST) Date: Thu, 5 Nov 2020 14:30:23 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: Mark Brown , Andre Przywara , Will Deacon , Catalin Marinas , Russell King , Linux ARM , kvmarm , Linux Kernel Mailing List , Sudeep Holla , Lorenzo Pieralisi , Linus Walleij Subject: Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source Message-ID: <20201105143023.GI82102@C02TD0UTHF1T.local> References: <20201105125656.25259-1-andre.przywara@arm.com> <20201105125656.25259-5-andre.przywara@arm.com> <20201105134142.GA4856@sirena.org.uk> <20201105140322.GH82102@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote: > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote: > > On Thu, Nov 05, 2020 at 01:41:42PM +0000, Mark Brown wrote: > > > On Thu, Nov 05, 2020 at 12:56:55PM +0000, Andre Przywara wrote: > > That said, I'm not sure it's great to plumb this under the > > arch_get_random*() interfaces, e.g. given this measn that > > add_interrupt_randomness() will end up trapping to the host all the time > > when it calls arch_get_random_seed_long(). > > As it turns out, add_interrupt_randomness() isn't actually used on ARM. It's certainly called on arm64, per a warning I just hacked in: [ 1.083802] ------------[ cut here ]------------ [ 1.084802] add_interrupt_randomness called [ 1.085685] WARNING: CPU: 1 PID: 0 at drivers/char/random.c:1267 add_interrupt_randomness+0x2e8/0x318 [ 1.087599] Modules linked in: [ 1.088258] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.10.0-rc2-dirty #13 [ 1.089672] Hardware name: linux,dummy-virt (DT) [ 1.090659] pstate: 60400085 (nZCv daIf +PAN -UAO -TCO BTYPE=--) [ 1.091910] pc : add_interrupt_randomness+0x2e8/0x318 [ 1.092965] lr : add_interrupt_randomness+0x2e8/0x318 [ 1.094021] sp : ffff80001000be80 [ 1.094732] x29: ffff80001000be80 x28: ffff2d0c80209840 [ 1.095859] x27: 00000000137c3e3a x26: ffff8000100abdd0 [ 1.096978] x25: 0000000000000035 x24: ffff67918bda8000 [ 1.098100] x23: ffffc57c31923fe8 x22: 00000000fffedc14 [ 1.099224] x21: ffff2d0dbef796a0 x20: ffffc57c331d16a0 [ 1.100339] x19: ffffc57c33720a48 x18: 0000000000000010 [ 1.101459] x17: 0000000000000000 x16: 0000000000000002 [ 1.102578] x15: 00000000000000e7 x14: ffff80001000bb20 [ 1.103706] x13: 00000000ffffffea x12: ffffc57c337b56e8 [ 1.104821] x11: 0000000000000003 x10: ffffc57c3379d6a8 [ 1.105944] x9 : ffffc57c3379d700 x8 : 0000000000017fe8 [ 1.107073] x7 : c0000000ffffefff x6 : 0000000000000001 [ 1.108186] x5 : 0000000000057fa8 x4 : 0000000000000000 [ 1.109305] x3 : 00000000ffffffff x2 : ffffc57c337455d0 [ 1.110428] x1 : db8dc9c2a1e0f600 x0 : 0000000000000000 [ 1.111552] Call trace: [ 1.112083] add_interrupt_randomness+0x2e8/0x318 [ 1.113074] handle_irq_event_percpu+0x48/0x90 [ 1.114016] handle_irq_event+0x48/0xf8 [ 1.114826] handle_fasteoi_irq+0xa4/0x130 [ 1.115689] generic_handle_irq+0x30/0x48 [ 1.116528] __handle_domain_irq+0x64/0xc0 [ 1.117392] gic_handle_irq+0xc0/0x138 [ 1.118194] el1_irq+0xbc/0x180 [ 1.118870] arch_cpu_idle+0x20/0x30 [ 1.119630] default_idle_call+0x8c/0x350 [ 1.120479] do_idle+0x224/0x298 [ 1.121163] cpu_startup_entry+0x28/0x70 [ 1.121994] secondary_start_kernel+0x184/0x198 ... and I couldn't immediately spot why 32-bit arm would be different. Thanks, Mark.