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

On Tue, Jan 25, 2011 at 03:33:24PM -0800, Colin Cross wrote:
> I think there is an additional change needed to
> __und_usr_unknown/do_undefinstr.  do_undefinstr, which gets called
> directly in __und_usr as well as by mov pc, lr, expects regs->ARM_pc
> to be the fault address, and not the next PC, and gets called for 2 or
> 4 byte instructions.

It expects it to be the next PC:

asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
{
        unsigned int correction = thumb_mode(regs) ? 2 : 4;
        unsigned int instr;
        siginfo_t info;
        void __user *pc;

        /*
         * According to the ARM ARM, PC is 2 or 4 bytes ahead,
         * depending whether we're in Thumb mode or not.
         * Correct this offset.
         */
        regs->ARM_pc -= correction;

We expect the PC to be pointing at the next instruction to be executed.
This is the value of the PC saved by the CPU when entering the exception.
We correct the PC by four bytes for ARM mode to point at the previously
executed instruction.

For 16-bit Thumb mode, the PC is again pointing at the next instruction
to be executed, and this is the value saved by the CPU.  So we correct
the PC by two bytes as that is the Thumb instruction size.

The problem comes with T2, where we advance the saved PC by two bytes
if the instruction was 32-bit such that it again points at the next
instruction to be executed.  This is where the problem comes in because
we have two different chunks of code with completely different
expectations.

Maybe we need to pass in the correction factor to do_undefinstr instead.
--
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/