Infinite loop?

[LawrenceRRogers]

On Fedora 32, I am trying to construct a json for Volatility 3. I have built dwarf2json version 0.6.0 from https://github.com/volatilityfoundation/dwarf2json under Fedora 32 using golang-1.14.3-1. The build is successful, that is there are no errors. I then installed both kernel-debuginfo-5.6.15-300.fc32.x86_64 and kernel-debuginfo-common-x86_64-5.6.15-300.fc32.x86_64. I ran dwarf2json as follows:

$ dwarf2json-fc32x linux --elf /usr/lib/debug/usr/lib/modules/5.6.15-300.fc32.x86_64/vmlinux --system-map /boot/System.map-5.6.15-300.fc32.x86_64

and I get the errors noted in the attached text file
dwarf2json-error-001.txt

I received a recommendation from the Volatility 3 developer group that felt the issue was with dwarf2json which is why I am posting this note.

Thanks for any help. I have the same problem on Fedora 29 and CentOS 7.8.

[ilch1]

I was able to reproduce this behavior. The problem appears to be in the dwarf golang package.
For anonymous structs, dwarf2json calls Defn() to derive an identifier for struct name.

1. Defn() iterates over the fields in the struct and calls f.type.String() for each one.
2. In the problematic case, it calls the String() for PtrType.
3. The String() function calls t.Type.String(), the String() for StructType. If the struct doesn't have a name, Defn() is called. This results in going back to (1).

I haven't been able to identify the Linux structure that is causing the problem. The long term solution would involve a fix in golang dwarf package. A short term solution would involve modifying how dwarf2json names anonymous types.

[LawrenceRRogers]

Can someone make the changes given in the suggestion from above? That would be much appreciated.

[ikelos]

I don't think this has been resolved yet, so reopening so we don't lose track...

[ilch1]

The dwarf entry being processed when the problem occurs has the following definition:

&{Offset:2391 Tag:StructType Children:true Field:[{Attr:Name Val:isk_activity36 Class:ClassString} {Attr:ByteSize Val:16448 Class:ClassConstant} {Attr:Attr(136) Val:64 Class:ClassConstant} {Attr:DeclFile Val:23 Class:ClassConstant} {Attr:DeclLine Val:629 Class:ClassConstant} {Attr:DeclColumn Val:8 Class:ClassConstant} {Attr:Sibling Val:5971 Class:ClassReference}]}

It is not clear what type this is. It appears that golang dwarf library has trouble parsing the data.

The entry at the same offset (2391 == 0x957) as reported by dwarfdump is:

0x00000957:   DW_TAG_structure_type
                DW_AT_name      ("task_struct")
                DW_AT_byte_size (0x4040)
                DW_AT_alignment (0x40)
                DW_AT_decl_file ("/usr/src/debug/kernel-5.6.fc32/linux-5.6.15-300.fc32.x86_64/./include/linux/sched.h")
                DW_AT_decl_line (629)
                DW_AT_decl_column       (0x08)
                DW_AT_sibling   (0x00001753)

0x00000967:     DW_TAG_member
                  DW_AT_name    ("thread_info")
                  DW_AT_decl_file       ("/usr/src/debug/kernel-5.6.fc32/linux-5.6.15-300.fc32.x86_64/./include/linux/sched.h")
                  DW_AT_decl_line       (635)
                  DW_AT_decl_column     (0x16)
                  DW_AT_type    (0x00003ce9 "thread_info")
                  DW_AT_data_member_location    (0x00)

0x00000975:     DW_TAG_member
                  DW_AT_name    ("state")
                  DW_AT_decl_file       ("/usr/src/debug/kernel-5.6.fc32/linux-5.6.15-300.fc32.x86_64/./include/linux/sched.h")
                  DW_AT_decl_line       (638)
                  DW_AT_decl_column     (0x12)
                  DW_AT_type    (0x000001a6 "volatile long int")
                  DW_AT_data_member_location    (0x10)

0x00000983:     DW_TAG_member
                  DW_AT_name    ("stack")
                  DW_AT_decl_file       ("/usr/src/debug/kernel-5.6.fc32/linux-5.6.15-300.fc32.x86_64/./include/linux/sched.h")
                  DW_AT_decl_line       (646)
                  DW_AT_decl_column     (0x0b)
                  DW_AT_type    (0x0000042f "*")
                  DW_AT_data_member_location    (0x18)

[continues]

The definition for task_struct can be found in include/linux/sched.h.

struct task_struct {
#ifdef CONFIG_THREAD_INFO_IN_TASK
	/*
	 * For reasons of header soup (see current_thread_info()), this
	 * must be the first element of task_struct.
	 */
	struct thread_info		thread_info;
#endif
	/* -1 unrunnable, 0 runnable, >0 stopped: */
	volatile long			state;

	/*
	 * This begins the randomizable portion of task_struct. Only
	 * scheduling-critical items should be added above here.
	 */
	randomized_struct_fields_start

	void				*stack;
[continues]

[npetroni]

I debugged this a bit and it appears to be related to ELF relocations being applied when they shouldn't be, prior to DWARF parsing. Removing relocations fixes at least one test case, but may introduce other regressions. I've pushed a branch, but we will need to do more testing and analysis, and perhaps discuss whether this might also be an issue for Mach-O.

[ilch1]

Hi @LawrenceRRogers, could you verify that PR #28 (issue-15-elf-relocations branch) solves your original issue?

[ilch1]

PR #28 is now merged. Please reopen this issue if that fix doesn't work for your use case.