linux-kernel - Re: [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 08 Mar 2021 22:42:47 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Hector Martin <marcan@...can.st>,
        linux-arm-kernel@...ts.infradead.org,
        Arnd Bergmann <arnd@...nel.org>,
        Olof Johansson <olof@...om.net>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Tony Lindgren <tony@...mide.com>,
        Mohamed Mediouni <mohamed.mediouni@...amail.com>,
        Stan Skowronek <stan@...ellium.com>,
        Alexander Graf <graf@...zon.com>,
        Will Deacon <will@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Hellwig <hch@...radead.org>,
        "David S. Miller" <davem@...emloft.net>,
        devicetree@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: Add interrupt-names support

On Mon, 08 Mar 2021 20:38:41 +0000,
Rob Herring <robh@...nel.org> wrote:
> 
> On Fri, Mar 05, 2021 at 06:38:41AM +0900, Hector Martin wrote:
> > Not all platforms provide the same set of timers/interrupts, and Linux
> > only needs one (plus kvm/guest ones); some platforms are working around
> > this by using dummy fake interrupts. Implementing interrupt-names allows
> > the devicetree to specify an arbitrary set of available interrupts, so
> > the timer code can pick the right one.
> > 
> > This also adds the hyp-virt timer/interrupt, which was previously not
> > expressed in the fixed 4-interrupt form.
> > 
> > Signed-off-by: Hector Martin <marcan@...can.st>
> > ---
> >  .../devicetree/bindings/timer/arm,arch_timer.yaml  | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > index 2c75105c1398..ebe9b0bebe41 100644
> > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > @@ -34,11 +34,25 @@ properties:
> >                - arm,armv8-timer
> >  
> >    interrupts:
> > +    minItems: 1
> > +    maxItems: 5
> >      items:
> >        - description: secure timer irq
> >        - description: non-secure timer irq
> >        - description: virtual timer irq
> >        - description: hypervisor timer irq
> > +      - description: hypervisor virtual timer irq
> > +
> > +  interrupt-names:
> > +    minItems: 1
> > +    maxItems: 5
> > +    items:
> > +      enum:
> > +        - phys-secure
> > +        - phys
> > +        - virt
> > +        - hyp-phys
> > +        - hyp-virt
> 
> phys-secure and hyp-phys is not very consistent. secure-phys or sec-phys 
> instead?
> 
> This allows any order which is not ideal (unfortunately json-schema 
> doesn't have a way to define order with optional entries in the middle). 
> How many possible combinations are there which make sense? If that's a 
> reasonable number, I'd rather see them listed out.

The available of interrupts are a function of the number of security
states, privileged exception levels and architecture revisions, as
described in D11.1.1:

<quote>
- An EL1 physical timer.
- A Non-secure EL2 physical timer.
- An EL3 physical timer.
- An EL1 virtual timer.
- A Non-secure EL2 virtual timer.
- A Secure EL2 virtual timer.
- A Secure EL2 physical timer.
</quote>

* Single security state, EL1 only, ARMv7 & ARMv8.0+ (assumed NS):
  - physical, virtual

* Single security state, EL1 + EL2, ARMv7 & ARMv8.0 (assumed NS)
  - physical, virtual, hyp physical

* Single security state, EL1 + EL2, ARMv8.1+ (assumed NS)
  - physical, virtual, hyp physical, hyp virtual

* Two security states, EL1 + EL3, ARMv7 & ARMv8.0+:
  - secure physical, physical, virtual

* Two security states, EL1 + EL2 + EL3, ARMv7 & ARMv8.0
  - secure physical, physical, virtual, hyp physical

* Two security states, EL1 + EL2 + EL3, ARMv8.1+
  - secure physical, physical, virtual, hyp physical, hyp virtual

* Two security states, EL1 + EL2 + S-EL2 + EL3, ARMv8.4+
  - secure physical, physical, virtual, hyp physical, hyp virtual,
    secure hyp physical, secure hyp virtual

Nobody has seen the last combination in the wild (that is, outside of
a SW model).

I'm really not convinced we want to express this kind of complexity in
the binding (each of the 7 cases), specially given that we don't
encode the underlying HW architecture level or number of exception
levels anywhere, and have ho way to validate such information.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.