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
next 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: linkBe 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).