linux-kernel - [PATCH] ARM: vfp: Fix up exception location in Thumb mode

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:	Sun, 16 Jan 2011 11:49:21 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Colin Cross <ccross@...roid.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH] ARM: vfp: Fix up exception location in Thumb mode

On Saturday, 15 January 2011, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Sat, Jan 15, 2011 at 03:31:04PM +0000, Catalin Marinas wrote:
>> On 14 January 2011 17:30, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> > index 2b46fea..5876eec 100644
>> > --- a/arch/arm/kernel/entry-armv.S
>> > +++ b/arch/arm/kernel/entry-armv.S
>> > @@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
>> >        .align  5
>> >  __und_usr:
>> >        usr_entry
>> > -
>> > -       @
>> > -       @ fall through to the emulation code, which returns using r9 if
>> > -       @ it has emulated the instruction, or the more conventional lr
>> > -       @ if we are to treat this as a real undefined instruction
>> >        @
>> > -       @  r0 - instruction
>> > +       @ The emulation code returns using r9 if it has emulated the
>> > +       @ instruction, or the more conventional lr if we are to treat
>> > +       @ this as a real undefined instruction
>> >        @
>> >        adr     r9, BSYM(ret_from_exception)
>> >        adr     lr, BSYM(__und_usr_unknown)
>> > +       @
>> > +       @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
>> > +       @ faulting instruction depending on Thumb mode.
>> > +       @ r3 = regs->ARM_cpsr
>> > +       @
>> >        tst     r3, #PSR_T_BIT                  @ Thumb mode?
>> > -       itet    eq                              @ explicit IT needed for the 1f label
>> > +       itttt   eq                              @ explicit IT needed for the 1f label
>> >        subeq   r4, r2, #4                      @ ARM instr at LR - 4
>> > -       subne   r4, r2, #2                      @ Thumb instr at LR - 2
>> >  1:     ldreqt  r0, [r4]
>>
>> The itttt above should just be itt. The reveq is conditionally
>> compiled and beq doesn't necessarily need one.
>
> It's a reveq, so I thought we should cover all the instructions with
> an 'eq' conditional for thumb.

If the it instruction doesn't cover all instructions, gas generates
some more its. But in this case, for little endian, the it instruction
covers more since reveq isn't included and having the beq not last in
the block I think is unpredictable. If you really want to optimise the
big endian case not to have an additional it generated by gas, you can
write ittt so that beq is included with little endian but not with big
endian. I wouldn't bother much for an extra it anyway.

>> >  #ifdef CONFIG_CPU_ENDIAN_BE8
>> >        reveq   r0, r0                          @ little endian instruction
>> >  #endif
>> > +       @
>> > +       @ r0 = 32-bit ARM instruction which caused the exception
>> > +       @ r2 = PC value for the following instruction (:= regs->ARM_pc)
>>
>> Is r2 here always the PC value following instruction? If the Thumb
>> instruction was 32-bit, it just points in the middle of the faulting
>> instruction.
>
> Is the T bit ever zero in this case?  The code here is:
>
>         tst     r3, #PSR_T_BIT
>         subeq   r4, r2, #4
> 1:      ldreqt  r0, [r4]
>         reveq   r0, r0
>         beq     call_fpe

You can have the T bit set but the instruction a 32-bit Thumb in which
case r2 is in the middle of such instruction rather than the next.
Unless you only refer to the ARM mode, in which case the comment is
fine.

> So, if !T, then we subtract 4 and load the instruction (which was the
> faulting instruction).  So r2 is the following instruction.
>
> Ah, maybe you're getting confused by the comment.  Should we put
> an 'eq' suffix on the end of each line? ;)

Maybe mention that this is ARM. I think documenting this code is
difficult anyway. I found myself not reading the comments at all when
revisiting this code :) but they may be useful for others.


-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/