[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXEoot13bFKywPRVf4BFhA5tSp+Nate=+Z+JsQdLW1oRrg@mail.gmail.com>
Date: Thu, 5 Nov 2020 15:34:01 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Mark Rutland <mark.rutland@....com>, Marc Zyngier <maz@...nel.org>
Cc: Mark Brown <broonie@...nel.org>,
Andre Przywara <andre.przywara@....com>,
Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Russell King <linux@...linux.org.uk>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
kvmarm <kvmarm@...ts.cs.columbia.edu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sudeep Holla <sudeep.holla@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source
On Thu, 5 Nov 2020 at 15:30, Mark Rutland <mark.rutland@....com> wrote:
>
> On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> > On Thu, 5 Nov 2020 at 15:03, Mark Rutland <mark.rutland@....com> 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.
>
Hmm, I actually meant both arm64 and ARM.
Marc looked into this at my request a while ago, and I had a look
myself as well at the time, and IIRC, we both concluded that we don't
hit that code path. Darn.
In any case, the way add_interrupt_randomness() calls
arch_get_random_seed_long() is absolutely insane, so we should try to
fix that in any case.
Powered by blists - more mailing lists