[0/3] Add support for Graviton TRNG

Message

Ali Saidi June 4, 2019, 8:30 p.m. UTC

AWS Graviton based systems provide an Arm SMC call in the vendor defined
hypervisor region to read random numbers from a HW TRNG and return them to the
guest. 

We've observed slower guest boot and especially reboot times due to lack of
entropy and providing access to a TRNG is meant to address this. 

Ali Saidi (3):
  arm/arm64: Add smccc hypervisor service identifiers
  arm64: export acpi_psci_use_hvc
  hwrng: Add support for AWS Graviton TRNG

 MAINTAINERS                           |   6 ++
 arch/arm64/kernel/acpi.c              |   1 +
 drivers/char/hw_random/Kconfig        |  13 ++++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/graviton-rng.c | 123 ++++++++++++++++++++++++++++++++++
 include/linux/arm-smccc.h             |   2 +
 6 files changed, 146 insertions(+)
 create mode 100644 drivers/char/hw_random/graviton-rng.c

Comments

Will Deacon June 5, 2019, 12:20 p.m. UTC | #1

On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
> AWS Graviton based systems provide an Arm SMC call in the vendor defined
> hypervisor region to read random numbers from a HW TRNG and return them to the
> guest. 
> 
> We've observed slower guest boot and especially reboot times due to lack of
> entropy and providing access to a TRNG is meant to address this. 

Curious, but why this over something like virtio-rng?

Will

Ali Saidi June 7, 2019, 12:58 p.m. UTC | #2

On 6/5/19, 7:20 AM, "Will Deacon" <[e-mail]> wrote:

    On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
    > AWS Graviton based systems provide an Arm SMC call in the vendor defined
    > hypervisor region to read random numbers from a HW TRNG and return them to the
    > guest. 
    > 
    > We've observed slower guest boot and especially reboot times due to lack of
    > entropy and providing access to a TRNG is meant to address this. 
    
    Curious, but why this over something like virtio-rng?
    
This interface allows us to provide the functionality from both EL2 and EL3 and support multiple different types of our instances which we unfortunately can't do with virt-io.

Ali

Ali Saidi June 28, 2019, 6:05 p.m. UTC | #3

On 6/7/19, 7:59 AM, " Ali Saidi" <[e-mail]> wrote:

    
    
    On 6/5/19, 7:20 AM, "Will Deacon" <[e-mail]> wrote:
    
        On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
        > AWS Graviton based systems provide an Arm SMC call in the vendor defined
        > hypervisor region to read random numbers from a HW TRNG and return them to the
        > guest. 
        > 
        > We've observed slower guest boot and especially reboot times due to lack of
        > entropy and providing access to a TRNG is meant to address this. 
        
        Curious, but why this over something like virtio-rng?
        
    This interface allows us to provide the functionality from both EL2 and EL3 and support multiple different types of our instances which we unfortunately can't do with virt-io.
    
Will,

Any additional comments?

Mark,

Do you know when you'll have a chance to rebase arm64/smccc-cleanup?

Thanks,
Ali

Will Deacon July 1, 2019, 8:28 a.m. UTC | #4

[Note: this was in my spam folder]

On Fri, Jun 28, 2019 at 06:05:10PM +0000, Saidi, Ali wrote:
> On 6/7/19, 7:59 AM, " Ali Saidi" <[e-mail]> wrote:
>     On 6/5/19, 7:20 AM, "Will Deacon" <[e-mail]> wrote:
>         On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
>         > AWS Graviton based systems provide an Arm SMC call in the vendor defined
>         > hypervisor region to read random numbers from a HW TRNG and return them to the
>         > guest. 
>         > 
>         > We've observed slower guest boot and especially reboot times due to lack of
>         > entropy and providing access to a TRNG is meant to address this. 
>         
>         Curious, but why this over something like virtio-rng?
>         
>     This interface allows us to provide the functionality from both EL2
>     and EL3 and support multiple different types of our instances which we
>     unfortunately can't do with virt-io.
>     
> Any additional comments?
> Do you know when you'll have a chance to rebase arm64/smccc-cleanup?

Sorry, Ali, this slipped through the cracks. Marc and I will chat today and
look at respinning what we had before; it should then hopefully be
straightforward enough for you to take that as a base for what you want to
do.

Will

Will Deacon July 1, 2019, 5:02 p.m. UTC | #5

[+Marc]

On Mon, Jul 01, 2019 at 09:28:06AM +0100, Will Deacon wrote:
> [Note: this was in my spam folder]
> 
> On Fri, Jun 28, 2019 at 06:05:10PM +0000, Saidi, Ali wrote:
> > On 6/7/19, 7:59 AM, " Ali Saidi" <[e-mail]> wrote:
> >     On 6/5/19, 7:20 AM, "Will Deacon" <[e-mail]> wrote:
> >         On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
> >         > AWS Graviton based systems provide an Arm SMC call in the vendor defined
> >         > hypervisor region to read random numbers from a HW TRNG and return them to the
> >         > guest. 
> >         > 
> >         > We've observed slower guest boot and especially reboot times due to lack of
> >         > entropy and providing access to a TRNG is meant to address this. 
> >         
> >         Curious, but why this over something like virtio-rng?
> >         
> >     This interface allows us to provide the functionality from both EL2
> >     and EL3 and support multiple different types of our instances which we
> >     unfortunately can't do with virt-io.
> >     
> > Any additional comments?
> > Do you know when you'll have a chance to rebase arm64/smccc-cleanup?
> 
> Sorry, Ali, this slipped through the cracks. Marc and I will chat today and
> look at respinning what we had before; it should then hopefully be
> straightforward enough for you to take that as a base for what you want to
> do.

Ok, I hacked on this a bit today and hopefully you can use this as a
starting point:

https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=kvm/hvc

I haven't given it any real testing, so apologies for the bugs.

Will