diff mbox series

[for-2.12] hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses

Message ID 20180315133441.24149-1-peter.maydell@linaro.org
State Superseded
Headers show
Series [for-2.12] hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses | expand

Commit Message

Peter Maydell March 15, 2018, 1:34 p.m. UTC 
If the GIC has the security extension support enabled, then a
non-secure access to ICC_PMR must take account of the non-secure
view of interrupt priorities, where real priorities 0..0x7f
are secure-only and not visible to the non-secure guest, and
priorities 0x80..0xff are shown to the guest as if they were
0x00..0xff. We had the logic here wrong:
 * on reads, the priority is in the secure range if bit 7
   is clear, not if it is set
 * on writes, we want to set bit 7, not mask everything else

Our ICC_RPR read code had the same error as ICC_PMR.

(Compare the GICv3 spec pseudocode functions ICC_RPR_EL1
and ICC_PMR_EL1.)

Fixes: https://bugs.launchpad.net/qemu/+bug/1748434
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

---
 hw/intc/arm_gicv3_cpuif.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.16.2

Comments

Peter Maydell March 22, 2018, 12:51 p.m. UTC | #1 
Ping for code review -- it would be nice to put this bugfix
into rc1.

thanks
-- PMM

On 15 March 2018 at 13:34, Peter Maydell <peter.maydell@linaro.org> wrote:
> If the GIC has the security extension support enabled, then a

> non-secure access to ICC_PMR must take account of the non-secure

> view of interrupt priorities, where real priorities 0..0x7f

> are secure-only and not visible to the non-secure guest, and

> priorities 0x80..0xff are shown to the guest as if they were

> 0x00..0xff. We had the logic here wrong:

>  * on reads, the priority is in the secure range if bit 7

>    is clear, not if it is set

>  * on writes, we want to set bit 7, not mask everything else

>

> Our ICC_RPR read code had the same error as ICC_PMR.

>

> (Compare the GICv3 spec pseudocode functions ICC_RPR_EL1

> and ICC_PMR_EL1.)

>

> Fixes: https://bugs.launchpad.net/qemu/+bug/1748434

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>  hw/intc/arm_gicv3_cpuif.c | 6 +++---

>  1 file changed, 3 insertions(+), 3 deletions(-)

>

> diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c

> index 5cbafaf497..26f5eeda94 100644

> --- a/hw/intc/arm_gicv3_cpuif.c

> +++ b/hw/intc/arm_gicv3_cpuif.c

> @@ -836,7 +836,7 @@ static uint64_t icc_pmr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>          /* NS access and Group 0 is inaccessible to NS: return the

>           * NS view of the current priority

>           */

> -        if (value & 0x80) {

> +        if ((value & 0x80) == 0) {

>              /* Secure priorities not visible to NS */

>              value = 0;

>          } else if (value != 0xff) {

> @@ -871,7 +871,7 @@ static void icc_pmr_write(CPUARMState *env, const ARMCPRegInfo *ri,

>              /* Current PMR in the secure range, don't allow NS to change it */

>              return;

>          }

> -        value = (value >> 1) & 0x80;

> +        value = (value >> 1) | 0x80;

>      }

>      cs->icc_pmr_el1 = value;

>      gicv3_cpuif_update(cs);

> @@ -1609,7 +1609,7 @@ static uint64_t icc_rpr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>      if (arm_feature(env, ARM_FEATURE_EL3) &&

>          !arm_is_secure(env) && (env->cp15.scr_el3 & SCR_FIQ)) {

>          /* NS GIC access and Group 0 is inaccessible to NS */

> -        if (prio & 0x80) {

> +        if ((prio & 0x80) == 0) {

>              /* NS mustn't see priorities in the Secure half of the range */

>              prio = 0;

>          } else if (prio != 0xff) {

> --

> 2.16.2
Andrew Jones March 22, 2018, 2:23 p.m. UTC | #2 
On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:
> If the GIC has the security extension support enabled, then a

> non-secure access to ICC_PMR must take account of the non-secure

> view of interrupt priorities, where real priorities 0..0x7f

> are secure-only and not visible to the non-secure guest, and

> priorities 0x80..0xff are shown to the guest as if they were

> 0x00..0xff. We had the logic here wrong:


0x00..0x7f

>  * on reads, the priority is in the secure range if bit 7

>    is clear, not if it is set

>  * on writes, we want to set bit 7, not mask everything else

> 

> Our ICC_RPR read code had the same error as ICC_PMR.

> 

> (Compare the GICv3 spec pseudocode functions ICC_RPR_EL1

> and ICC_PMR_EL1.)

> 

> Fixes: https://bugs.launchpad.net/qemu/+bug/1748434

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>  hw/intc/arm_gicv3_cpuif.c | 6 +++---

>  1 file changed, 3 insertions(+), 3 deletions(-)

> 

> diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c

> index 5cbafaf497..26f5eeda94 100644

> --- a/hw/intc/arm_gicv3_cpuif.c

> +++ b/hw/intc/arm_gicv3_cpuif.c

> @@ -836,7 +836,7 @@ static uint64_t icc_pmr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>          /* NS access and Group 0 is inaccessible to NS: return the

>           * NS view of the current priority

>           */

> -        if (value & 0x80) {

> +        if ((value & 0x80) == 0) {

>              /* Secure priorities not visible to NS */

>              value = 0;

>          } else if (value != 0xff) {

> @@ -871,7 +871,7 @@ static void icc_pmr_write(CPUARMState *env, const ARMCPRegInfo *ri,

>              /* Current PMR in the secure range, don't allow NS to change it */

>              return;

>          }

> -        value = (value >> 1) & 0x80;

> +        value = (value >> 1) | 0x80;

>      }

>      cs->icc_pmr_el1 = value;

>      gicv3_cpuif_update(cs);

> @@ -1609,7 +1609,7 @@ static uint64_t icc_rpr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>      if (arm_feature(env, ARM_FEATURE_EL3) &&

>          !arm_is_secure(env) && (env->cp15.scr_el3 & SCR_FIQ)) {

>          /* NS GIC access and Group 0 is inaccessible to NS */

> -        if (prio & 0x80) {

> +        if ((prio & 0x80) == 0) {

>              /* NS mustn't see priorities in the Secure half of the range */

>              prio = 0;

>          } else if (prio != 0xff) {

> -- 

> 2.16.2

> 

>


Reviewed-by: Andrew Jones <drjones@redhat.com>
Peter Maydell March 22, 2018, 6:29 p.m. UTC | #3 
On 22 March 2018 at 14:23, Andrew Jones <drjones@redhat.com> wrote:
> On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:

>> If the GIC has the security extension support enabled, then a

>> non-secure access to ICC_PMR must take account of the non-secure

>> view of interrupt priorities, where real priorities 0..0x7f

>> are secure-only and not visible to the non-secure guest, and

>> priorities 0x80..0xff are shown to the guest as if they were

>> 0x00..0xff. We had the logic here wrong:

>

> 0x00..0x7f


I think 0x00..0xff is correct. The conversion from actual
priority value to the NS-view is
   if (prio & 0x80 == 0) {
       nsview = 0;
   } else {
       nsview = (prio << 1) & 0xff;
   }

so:
   real priority     NS view
    0x80              0x00
    0x90              0x20
    0xa0              0x40
    0xb0              0x60
    0xc0              0x80
    0xd0              0xa0
    0xe0              0xc0
    0xf0              0xe0

the NS view covers the whole 0x00..0xff range, but more sparsely.
(OK, technically you can't ever read 0xff, only 0xfe.)

> Reviewed-by: Andrew Jones <drjones@redhat.com>


Thanks for the review.

-- PMM
Philippe Mathieu-Daudé March 22, 2018, 8:42 p.m. UTC | #4 
Hi Peter,

On 03/22/2018 03:29 PM, Peter Maydell wrote:
> On 22 March 2018 at 14:23, Andrew Jones <drjones@redhat.com> wrote:

>> On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:

>>> If the GIC has the security extension support enabled, then a

>>> non-secure access to ICC_PMR must take account of the non-secure

>>> view of interrupt priorities, where real priorities 0..0x7f

>>> are secure-only and not visible to the non-secure guest, and

>>> priorities 0x80..0xff are shown to the guest as if they were

>>> 0x00..0xff. We had the logic here wrong:

>>

>> 0x00..0x7f

> 

> I think 0x00..0xff is correct.


I guess Andrew only suggested to correct the hex prefix in your comment:
- ... where real priorities 0..0x7f
+ ... where real priorities 0x00..0x7f

> The conversion from actual

> priority value to the NS-view is

>    if (prio & 0x80 == 0) {

>        nsview = 0;

>    } else {

>        nsview = (prio << 1) & 0xff;

>    }

> 

> so:

>    real priority     NS view

>     0x80              0x00

>     0x90              0x20

>     0xa0              0x40

>     0xb0              0x60

>     0xc0              0x80

>     0xd0              0xa0

>     0xe0              0xc0

>     0xf0              0xe0

> 

> the NS view covers the whole 0x00..0xff range, but more sparsely.

> (OK, technically you can't ever read 0xff, only 0xfe.)
Philippe Mathieu-Daudé March 23, 2018, 2:23 a.m. UTC | #5 
On 03/15/2018 10:34 AM, Peter Maydell wrote:
> If the GIC has the security extension support enabled, then a

> non-secure access to ICC_PMR must take account of the non-secure

> view of interrupt priorities, where real priorities 0..0x7f

> are secure-only and not visible to the non-secure guest, and

> priorities 0x80..0xff are shown to the guest as if they were

> 0x00..0xff. We had the logic here wrong:

>  * on reads, the priority is in the secure range if bit 7

>    is clear, not if it is set

>  * on writes, we want to set bit 7, not mask everything else

> 

> Our ICC_RPR read code had the same error as ICC_PMR.

> 

> (Compare the GICv3 spec pseudocode functions ICC_RPR_EL1

> and ICC_PMR_EL1.)

> 

> Fixes: https://bugs.launchpad.net/qemu/+bug/1748434

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


> ---

>  hw/intc/arm_gicv3_cpuif.c | 6 +++---

>  1 file changed, 3 insertions(+), 3 deletions(-)

> 

> diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c

> index 5cbafaf497..26f5eeda94 100644

> --- a/hw/intc/arm_gicv3_cpuif.c

> +++ b/hw/intc/arm_gicv3_cpuif.c

> @@ -836,7 +836,7 @@ static uint64_t icc_pmr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>          /* NS access and Group 0 is inaccessible to NS: return the

>           * NS view of the current priority

>           */

> -        if (value & 0x80) {

> +        if ((value & 0x80) == 0) {

>              /* Secure priorities not visible to NS */

>              value = 0;

>          } else if (value != 0xff) {

> @@ -871,7 +871,7 @@ static void icc_pmr_write(CPUARMState *env, const ARMCPRegInfo *ri,

>              /* Current PMR in the secure range, don't allow NS to change it */

>              return;

>          }

> -        value = (value >> 1) & 0x80;

> +        value = (value >> 1) | 0x80;

>      }

>      cs->icc_pmr_el1 = value;

>      gicv3_cpuif_update(cs);

> @@ -1609,7 +1609,7 @@ static uint64_t icc_rpr_read(CPUARMState *env, const ARMCPRegInfo *ri)

>      if (arm_feature(env, ARM_FEATURE_EL3) &&

>          !arm_is_secure(env) && (env->cp15.scr_el3 & SCR_FIQ)) {

>          /* NS GIC access and Group 0 is inaccessible to NS */

> -        if (prio & 0x80) {

> +        if ((prio & 0x80) == 0) {

>              /* NS mustn't see priorities in the Secure half of the range */

>              prio = 0;

>          } else if (prio != 0xff) {

>
Peter Maydell March 23, 2018, 9:45 a.m. UTC | #6 
On 22 March 2018 at 20:42, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> Hi Peter,

>

> On 03/22/2018 03:29 PM, Peter Maydell wrote:

>> On 22 March 2018 at 14:23, Andrew Jones <drjones@redhat.com> wrote:

>>> On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:

>>>> If the GIC has the security extension support enabled, then a

>>>> non-secure access to ICC_PMR must take account of the non-secure

>>>> view of interrupt priorities, where real priorities 0..0x7f

>>>> are secure-only and not visible to the non-secure guest, and

>>>> priorities 0x80..0xff are shown to the guest as if they were

>>>> 0x00..0xff. We had the logic here wrong:

>>>

>>> 0x00..0x7f

>>

>> I think 0x00..0xff is correct.

>

> I guess Andrew only suggested to correct the hex prefix in your comment:

> - ... where real priorities 0..0x7f

> + ... where real priorities 0x00..0x7f


Oh, right. Yes, can do that. I was confused by the suggested correction
being directly under "0x00..0xff" in my commit message.

thanks
-- PMM
Andrew Jones March 23, 2018, 10:08 a.m. UTC | #7 
On Thu, Mar 22, 2018 at 05:42:02PM -0300, Philippe Mathieu-Daudé wrote:
> Hi Peter,

> 

> On 03/22/2018 03:29 PM, Peter Maydell wrote:

> > On 22 March 2018 at 14:23, Andrew Jones <drjones@redhat.com> wrote:

> >> On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:

> >>> If the GIC has the security extension support enabled, then a

> >>> non-secure access to ICC_PMR must take account of the non-secure

> >>> view of interrupt priorities, where real priorities 0..0x7f

> >>> are secure-only and not visible to the non-secure guest, and

> >>> priorities 0x80..0xff are shown to the guest as if they were

> >>> 0x00..0xff. We had the logic here wrong:

> >>

> >> 0x00..0x7f

> > 

> > I think 0x00..0xff is correct.

> 

> I guess Andrew only suggested to correct the hex prefix in your comment:

> - ... where real priorities 0..0x7f

> + ... where real priorities 0x00..0x7f


Actually I just hadn't thought that through properly. But thanks for
giving me the benefit of the doubt :-)

> > 

> > the NS view covers the whole 0x00..0xff range, but more sparsely.

> > (OK, technically you can't ever read 0xff, only 0xfe.)

> 


You can read 0xff, because 0xff will be written when either 0xfe or 0xff
are written. Then, when reading, priority == 0xff will fail the != 0xff
test (which is QEMU's implementation of the pseudo code where PRIMask()
is hardcoded to 0xff). In that case it'll just return the priority value
unchanged, which is 0xff.

Thanks,
drew
diff mbox series

Patch

diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 5cbafaf497..26f5eeda94 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -836,7 +836,7 @@  static uint64_t icc_pmr_read(CPUARMState *env, const ARMCPRegInfo *ri)
         /* NS access and Group 0 is inaccessible to NS: return the
          * NS view of the current priority
          */
-        if (value & 0x80) {
+        if ((value & 0x80) == 0) {
             /* Secure priorities not visible to NS */
             value = 0;
         } else if (value != 0xff) {
@@ -871,7 +871,7 @@  static void icc_pmr_write(CPUARMState *env, const ARMCPRegInfo *ri,
             /* Current PMR in the secure range, don't allow NS to change it */
             return;
         }
-        value = (value >> 1) & 0x80;
+        value = (value >> 1) | 0x80;
     }
     cs->icc_pmr_el1 = value;
     gicv3_cpuif_update(cs);
@@ -1609,7 +1609,7 @@  static uint64_t icc_rpr_read(CPUARMState *env, const ARMCPRegInfo *ri)
     if (arm_feature(env, ARM_FEATURE_EL3) &&
         !arm_is_secure(env) && (env->cp15.scr_el3 & SCR_FIQ)) {
         /* NS GIC access and Group 0 is inaccessible to NS */
-        if (prio & 0x80) {
+        if ((prio & 0x80) == 0) {
             /* NS mustn't see priorities in the Secure half of the range */
             prio = 0;
         } else if (prio != 0xff) {