[Bug 285677] vgic: Off-by-one error in its_init_cpu_lpi()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285677

            Bug ID: 285677
           Summary: vgic: Off-by-one error in its_init_cpu_lpi()
           Product: Base System
           Version: Unspecified
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]

The function its_init_cpu_lpi() will configure the LPIs for a given CPU. One
part is to configure the GICR_PROPBASER which contains, among other fields, the
size of the property table. This is computed as followed:

```
        size = (flsl(LPI_CONFTAB_SIZE | GIC_FIRST_LPI) - 1);

        xbaser = vtophys(sc->sc_conf_base) |
            (GICR_PROPBASER_SHARE_IS << GICR_PROPBASER_SHARE_SHIFT) |
            (GICR_PROPBASER_CACHE_NIWAWB << GICR_PROPBASER_CACHE_SHIFT) |
            size;
```

Per the GIC specification (12.11.31 in ARM IHI 069G), the ID bits is:

```
The number of bits of LPI INTID supported, minus one, by the LPI Configuration
table starting at Physical_Address.
```

As the function flsl returns the last bit set starting from 1 (e.g. if the
value 1 is passed, then the return is 1), I think the size should be computed
using
flsl(...) - 2.

The size is also used by the pending table which can't be touched by the OS
once the LPIs has been enabled:

```
During normal operation, the LPI Pending table is maintained solely by the
Redistributor.
Behavior is UNPREDICTABLE if software writes to the LPI Pending tables while
GICR_CTLR.EnableLPIs == 1.
When GICR_CTLR.EnableLPIs is cleared to 0, behavior is UNPREDICTABLE if the LPI
Pending table is written
before GICR_CTLR.RWP reads 0.
```

As we don't know the content past the region, this could lead to strange
behavior. Although, I am not aware of any issue right now.

This will also become a problem in confidential compute, because FreeBSD may
end up to declassify more memory than we should.

I am not posting a formal patch because I don't have a setup to build FreeBSD
yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.