xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Lukas Jünger" <lukas.juenger@ice.rwth-aachen.de>
To: xen-devel@lists.xenproject.org
Cc: Lukas Juenger <juenger@ice.rwth-aachen.de>
Subject: xen/arm: potential bug in advance_pc
Date: Tue, 14 May 2019 18:03:02 +0200	[thread overview]
Message-ID: <7f55fb96-0105-4e32-9cbd-1b842ed99509@rwthex-w1-a.rwth-ad.de> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1062 bytes --]

Hello all,

in the function advance_pc in xen/arch/arm/traps.c in line 1655,1656 you 
can find the following code:

1655     BUG_ON( (!psr_mode_is_32bit(cpsr)||!(cpsr&PSR_THUMB))
1656             && (cpsr&PSR_IT_MASK) );

This code seems to check that we are not running in thumb mode and that 
the PSR_IT_MASK is not set.
On ARMv8.5-BTI systems bits [11:10] of spsr_el2 indicate the BTYPE (see 
https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/spsr_el2).
If an exception is taken in the guest (e.g. write to system register) 
from AArch64 state these bits might be set.
The PSR_IT_MASK for thumb mode overlaps with these bits and BUG_ON is 
executed.
This seems to be a bug.
Is it really necessary to check the PSR_IT_MASK for BUG_ON here?
Why is the execution mode checked twice with psr_mode_is_32bit and 
cpsr&PSR_THUMB, as they seem to do the same thing?
If PSR_IT_MASK does not need to be checked for BUG_ON, the if statement 
in the following line should check for thumb mode again, right?

Best regards,
Lukas


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5388 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Lukas Jünger" <lukas.juenger@ice.rwth-aachen.de>
To: <xen-devel@lists.xenproject.org>
Cc: Lukas Juenger <juenger@ice.rwth-aachen.de>
Subject: [Xen-devel] xen/arm: potential bug in advance_pc
Date: Tue, 14 May 2019 18:03:02 +0200	[thread overview]
Message-ID: <7f55fb96-0105-4e32-9cbd-1b842ed99509@rwthex-w1-a.rwth-ad.de> (raw)
Message-ID: <20190514160302.OoK_E0qKIJ1Hh9ga8rxhhT_J4NcsfhbD1_MVYu-keKA@z> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1062 bytes --]

Hello all,

in the function advance_pc in xen/arch/arm/traps.c in line 1655,1656 you 
can find the following code:

1655     BUG_ON( (!psr_mode_is_32bit(cpsr)||!(cpsr&PSR_THUMB))
1656             && (cpsr&PSR_IT_MASK) );

This code seems to check that we are not running in thumb mode and that 
the PSR_IT_MASK is not set.
On ARMv8.5-BTI systems bits [11:10] of spsr_el2 indicate the BTYPE (see 
https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/spsr_el2).
If an exception is taken in the guest (e.g. write to system register) 
from AArch64 state these bits might be set.
The PSR_IT_MASK for thumb mode overlaps with these bits and BUG_ON is 
executed.
This seems to be a bug.
Is it really necessary to check the PSR_IT_MASK for BUG_ON here?
Why is the execution mode checked twice with psr_mode_is_32bit and 
cpsr&PSR_THUMB, as they seem to do the same thing?
If PSR_IT_MASK does not need to be checked for BUG_ON, the if statement 
in the following line should check for thumb mode again, right?

Best regards,
Lukas


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5388 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

             reply	other threads:[~2019-05-14 16:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 16:03 Lukas Jünger [this message]
2019-05-14 16:03 ` [Xen-devel] xen/arm: potential bug in advance_pc Lukas Jünger
2019-05-15 11:35 ` Julien Grall
2019-05-15 11:35   ` [Xen-devel] " Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f55fb96-0105-4e32-9cbd-1b842ed99509@rwthex-w1-a.rwth-ad.de \
    --to=lukas.juenger@ice.rwth-aachen.de \
    --cc=juenger@ice.rwth-aachen.de \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).