2022-10-10 10:11:24

by Zhen Lei

Subject: [PATCH v2 2/2] ARM: Make the dumped instructions are consistent with the disassembled ones

In ARM, the mapping of instruction memory is always little-endian, except
some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
endianness may be BE-32. Of course, its data endianness will also be BE-32
mode. Due to two negatives make a positive, the instruction stored in the
register after reading is in little-endian format. But for the case of
BE-8, the instruction endianness is LE, the instruction stored in the
register after reading is in big-endian format, which is inconsistent
with the disassembled one.

For example:
The content of disassembly:
c0429ee8: e3500000 cmp r0, #0
c0429eec: 159f2044 ldrne r2, [pc, #68]
c0429ef0: 108f2002 addne r2, pc, r2
c0429ef4: 1882000a stmne r2, {r1, r3}
c0429ef8: e7f000f0 udf #0

The output of undefined instruction exception:
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
... ...
Code: 000050e3 44209f15 02208f10 0a008218 (f000f0e7)

This inconveniences the checking of instructions. What's worse is that,
for somebody who don't know about this, might think the instructions are
all broken.

So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
little-endian format before they are printed. The conversion result is
as follows:
Code: e3500000 159f2044 108f2002 1882000a (e7f000f0)

Signed-off-by: Zhen Lei <[email protected]>
---
arch/arm/kernel/traps.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 34aa80c09c508c1..50b00c9091f079d 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
bad = get_user(val, &((u32 __user *)addr)[i]);
}

+ if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) {
+ if (thumb)
+ val = (__force unsigned int)cpu_to_le16(val);
+ else
+ val = (__force unsigned int)cpu_to_le32(val);
+ }
+
if (!bad)
p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
width, val);
--
2.25.1

2022-10-10 11:08:04

by Ard Biesheuvel

Subject: Re: [PATCH v2 2/2] ARM: Make the dumped instructions are consistent with the disassembled ones

On Mon, 10 Oct 2022 at 11:56, Zhen Lei <[email protected]> wrote:
>
> In ARM, the mapping of instruction memory is always little-endian, except
> some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
> endianness may be BE-32. Of course, its data endianness will also be BE-32
> mode. Due to two negatives make a positive, the instruction stored in the
> register after reading is in little-endian format. But for the case of
> BE-8, the instruction endianness is LE, the instruction stored in the
> register after reading is in big-endian format, which is inconsistent
> with the disassembled one.
>
> For example:
> The content of disassembly:
> c0429ee8: e3500000 cmp r0, #0
> c0429eec: 159f2044 ldrne r2, [pc, #68]
> c0429ef0: 108f2002 addne r2, pc, r2
> c0429ef4: 1882000a stmne r2, {r1, r3}
> c0429ef8: e7f000f0 udf #0
>
> The output of undefined instruction exception:
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ... ...
> Code: 000050e3 44209f15 02208f10 0a008218 (f000f0e7)
>
> This inconveniences the checking of instructions. What's worse is that,
> for somebody who don't know about this, might think the instructions are
> all broken.
>
> So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
> little-endian format before they are printed. The conversion result is
> as follows:
> Code: e3500000 159f2044 108f2002 1882000a (e7f000f0)
>
> Signed-off-by: Zhen Lei <[email protected]>
> ---
> arch/arm/kernel/traps.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 34aa80c09c508c1..50b00c9091f079d 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
> bad = get_user(val, &((u32 __user *)addr)[i]);
> }
>
> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) {
> + if (thumb)
> + val = (__force unsigned int)cpu_to_le16(val);

Better use swab16() here instead of the ugly __force cast, given that
the swab is going to occur unconditionally here.


> + else
> + val = (__force unsigned int)cpu_to_le32(val);

and swab32() here


> + }
> +
> if (!bad)
> p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
> width, val);
> --
> 2.25.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

2022-10-10 11:19:53

by Ard Biesheuvel

Subject: Re: [PATCH v2 2/2] ARM: Make the dumped instructions are consistent with the disassembled ones

On Mon, 10 Oct 2022 at 12:46, Leizhen (ThunderTown)
<[email protected]> wrote:
>
>
>
> On 2022/10/10 18:10, Ard Biesheuvel wrote:
> > On Mon, 10 Oct 2022 at 11:56, Zhen Lei <[email protected]> wrote:
> >>
> >> In ARM, the mapping of instruction memory is always little-endian, except
> >> some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
> >> endianness may be BE-32. Of course, its data endianness will also be BE-32
> >> mode. Due to two negatives make a positive, the instruction stored in the
> >> register after reading is in little-endian format. But for the case of
> >> BE-8, the instruction endianness is LE, the instruction stored in the
> >> register after reading is in big-endian format, which is inconsistent
> >> with the disassembled one.
> >>
> >> For example:
> >> The content of disassembly:
> >> c0429ee8: e3500000 cmp r0, #0
> >> c0429eec: 159f2044 ldrne r2, [pc, #68]
> >> c0429ef0: 108f2002 addne r2, pc, r2
> >> c0429ef4: 1882000a stmne r2, {r1, r3}
> >> c0429ef8: e7f000f0 udf #0
> >>
> >> The output of undefined instruction exception:
> >> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> >> ... ...
> >> Code: 000050e3 44209f15 02208f10 0a008218 (f000f0e7)
> >>
> >> This inconveniences the checking of instructions. What's worse is that,
> >> for somebody who don't know about this, might think the instructions are
> >> all broken.
> >>
> >> So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
> >> little-endian format before they are printed. The conversion result is
> >> as follows:
> >> Code: e3500000 159f2044 108f2002 1882000a (e7f000f0)
> >>
> >> Signed-off-by: Zhen Lei <[email protected]>
> >> ---
> >> arch/arm/kernel/traps.c | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> >> index 34aa80c09c508c1..50b00c9091f079d 100644
> >> --- a/arch/arm/kernel/traps.c
> >> +++ b/arch/arm/kernel/traps.c
> >> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
> >> bad = get_user(val, &((u32 __user *)addr)[i]);
> >> }
> >>
> >> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) {
> >> + if (thumb)
> >> + val = (__force unsigned int)cpu_to_le16(val);
> >
> > Better use swab16() here instead of the ugly __force cast, given that
> > the swab is going to occur unconditionally here.
>
> Good idea.
>
> >
> >
> >> + else
> >> + val = (__force unsigned int)cpu_to_le32(val);
> >
> > and swab32() here
>
> OK
>

Actually, come to think of it, should this code perhaps be using the
mem_to_opcode helpers that are being used elsewhere in the file?

2022-10-10 11:46:48

by Zhen Lei

Subject: Re: [PATCH v2 2/2] ARM: Make the dumped instructions are consistent with the disassembled ones

On 2022/10/10 18:10, Ard Biesheuvel wrote:
> On Mon, 10 Oct 2022 at 11:56, Zhen Lei <[email protected]> wrote:
>>
>> In ARM, the mapping of instruction memory is always little-endian, except
>> some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
>> endianness may be BE-32. Of course, its data endianness will also be BE-32
>> mode. Due to two negatives make a positive, the instruction stored in the
>> register after reading is in little-endian format. But for the case of
>> BE-8, the instruction endianness is LE, the instruction stored in the
>> register after reading is in big-endian format, which is inconsistent
>> with the disassembled one.
>>
>> For example:
>> The content of disassembly:
>> c0429ee8: e3500000 cmp r0, #0
>> c0429eec: 159f2044 ldrne r2, [pc, #68]
>> c0429ef0: 108f2002 addne r2, pc, r2
>> c0429ef4: 1882000a stmne r2, {r1, r3}
>> c0429ef8: e7f000f0 udf #0
>>
>> The output of undefined instruction exception:
>> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
>> ... ...
>> Code: 000050e3 44209f15 02208f10 0a008218 (f000f0e7)
>>
>> This inconveniences the checking of instructions. What's worse is that,
>> for somebody who don't know about this, might think the instructions are
>> all broken.
>>
>> So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
>> little-endian format before they are printed. The conversion result is
>> as follows:
>> Code: e3500000 159f2044 108f2002 1882000a (e7f000f0)
>>
>> Signed-off-by: Zhen Lei <[email protected]>
>> ---
>> arch/arm/kernel/traps.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 34aa80c09c508c1..50b00c9091f079d 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>> bad = get_user(val, &((u32 __user *)addr)[i]);
>> }
>>
>> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) {
>> + if (thumb)
>> + val = (__force unsigned int)cpu_to_le16(val);
>
> Better use swab16() here instead of the ugly __force cast, given that
> the swab is going to occur unconditionally here.

Good idea.

>
>
>> + else
>> + val = (__force unsigned int)cpu_to_le32(val);
>
> and swab32() here

OK

>
>
>> + }
>> +
>> if (!bad)
>> p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
>> width, val);
>> --
>> 2.25.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>

--
Regards,
Zhen Lei

2022-10-10 11:51:17

by Zhen Lei

Subject: Re: [PATCH v2 2/2] ARM: Make the dumped instructions are consistent with the disassembled ones

On 2022/10/10 19:07, Ard Biesheuvel wrote:
> On Mon, 10 Oct 2022 at 12:46, Leizhen (ThunderTown)
> <[email protected]> wrote:
>>
>>
>>
>> On 2022/10/10 18:10, Ard Biesheuvel wrote:
>>> On Mon, 10 Oct 2022 at 11:56, Zhen Lei <[email protected]> wrote:
>>>>
>>>> In ARM, the mapping of instruction memory is always little-endian, except
>>>> some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
>>>> endianness may be BE-32. Of course, its data endianness will also be BE-32
>>>> mode. Due to two negatives make a positive, the instruction stored in the
>>>> register after reading is in little-endian format. But for the case of
>>>> BE-8, the instruction endianness is LE, the instruction stored in the
>>>> register after reading is in big-endian format, which is inconsistent
>>>> with the disassembled one.
>>>>
>>>> For example:
>>>> The content of disassembly:
>>>> c0429ee8: e3500000 cmp r0, #0
>>>> c0429eec: 159f2044 ldrne r2, [pc, #68]
>>>> c0429ef0: 108f2002 addne r2, pc, r2
>>>> c0429ef4: 1882000a stmne r2, {r1, r3}
>>>> c0429ef8: e7f000f0 udf #0
>>>>
>>>> The output of undefined instruction exception:
>>>> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
>>>> ... ...
>>>> Code: 000050e3 44209f15 02208f10 0a008218 (f000f0e7)
>>>>
>>>> This inconveniences the checking of instructions. What's worse is that,
>>>> for somebody who don't know about this, might think the instructions are
>>>> all broken.
>>>>
>>>> So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
>>>> little-endian format before they are printed. The conversion result is
>>>> as follows:
>>>> Code: e3500000 159f2044 108f2002 1882000a (e7f000f0)
>>>>
>>>> Signed-off-by: Zhen Lei <[email protected]>
>>>> ---
>>>> arch/arm/kernel/traps.c | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>>>> index 34aa80c09c508c1..50b00c9091f079d 100644
>>>> --- a/arch/arm/kernel/traps.c
>>>> +++ b/arch/arm/kernel/traps.c
>>>> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>>>> bad = get_user(val, &((u32 __user *)addr)[i]);
>>>> }
>>>>
>>>> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) {
>>>> + if (thumb)
>>>> + val = (__force unsigned int)cpu_to_le16(val);
>>>
>>> Better use swab16() here instead of the ugly __force cast, given that
>>> the swab is going to occur unconditionally here.
>>
>> Good idea.
>>
>>>
>>>
>>>> + else
>>>> + val = (__force unsigned int)cpu_to_le32(val);
>>>
>>> and swab32() here
>>
>> OK
>>
>
> Actually, come to think of it, should this code perhaps be using the
> mem_to_opcode helpers that are being used elsewhere in the file?

Right, __mem_to_opcode_xxx is the correct solution. I need to test it.

> .
>

--
Regards,
Zhen Lei