On Wed, Jun 06, 2018 at 07:58:14PM -0700, Cyril Novikov wrote:
> Hello!
>
> libfdt fdt_num_mem_rsv() results in an unaligned access crash because the
> code "fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size" uses an aligned 64-bit read
> from an unaligned address. The platform is aarch64. The following is the
> generated code for fdt64_to_cpu():
>
> 1181ec: f94004e1 ldr x1, [x7, #8]
> 1181f0: 910040e7 add x7, x7, #0x10
> 1181f4: d3505c23 ubfx x3, x1, #16, #8
> 1181f8: d3483c22 ubfx x2, x1, #8, #8
> 1181fc: d3585c63 lsl x3, x3, #40
> 118200: d378fc26 lsr x6, x1, #56
> 118204: d3609c25 ubfx x5, x1, #32, #8
> 118208: aa02c062 orr x2, x3, x2, lsl #48
> 11820c: aa01e0c6 orr x6, x6, x1, lsl #56
> 118210: 53187c24 lsr w4, w1, #24
> 118214: d370dc23 ubfx x3, x1, #48, #8
> 118218: d3689ca5 lsl x5, x5, #24
> 11821c: aa060042 orr x2, x2, x6
> 118220: aa0480a4 orr x4, x5, x4, lsl #32
> 118224: d368bc21 ubfx x1, x1, #40, #8
> 118228: d378dc63 lsl x3, x3, #8
> 11822c: aa040042 orr x2, x2, x4
> 118230: aa014061 orr x1, x3, x1, lsl #16
> 118234: aa010041 orr x1, x2, x1
>
> The first instruction crashes because x7 is 4-byte aligned, but not 8-byte
> aligned.
>
> I'm not sure where the bug is. Is fdt64_to_cpu() supposed to convert the
> access to non-aligned and not doing its job properly?
No, it's not supposed to do that, because it can't do that: the memory
access happens *before* the value is passed to fdt64_to_cpu(). At the
source level, anyway, obviously it's likely they'll get optimized
together by the compiler.
What's odd here, is that the memory reserve section should be aligned
w.r.t the beginning othe device tree blob. So if you're hitting an
unaligned access here, it suggests that either
1) your blob doesn't have an aligned memrsv section
Which would definitely violate the dtb spec, and neither dtc nor
libfdt should generate such a tree.
2) The code that loads your blob isn't aligning it to 64-bits
That's not within the scope of the dtb spec as such, but aligning the
load is definitely a best practice.
That said, Peter Maydell has already pointed out that an accessor
which handles unaligned accesses would be a useful thing in libfdt
(mostly for loading from structured property values; they're always
packed and so can easily have unaligned values).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
