Re: [Crash-utility] Using crash with structure layout randomized kernel

On Thu, 25 Jan 2018 16:37:01 +0800 Cao jin <caoj.fnst(a)cn.fujitsu.com&gt; wrote: > On 01/24/2018 11:23 PM, Dave Anderson wrote: >> >> >> ----- Original Message ----- >>> >>> >>> On 01/23/2018 11:19 PM, Dave Anderson wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> Hi Dave, >>>>> >>>>>     Recently I was trying crash tool with kdump dumpfile & structure >>>>> layout randomized kernel[*](), and it fails without any surprise. After >>>>> looking into the different errors crash reports, I can confirm it is a >>>>> result from randomized structure layout. >>>>> >>>>> So my questions is, do you ever consider supporting this feature[*] in >>>>> crash? >>>>>   If yes, do you have any plan & technique evaluation about it? >>>>>   If no, what's the reason? >>>>> >>>>> [*]https://lwn.net/Articles/722293/ >>>>> -- >>>>> Sincerely, >>>>> Cao jin >>>> >>>> I was under the impression that the structure layout was done at >>>> compile-time, and that the vmlinux file's debuginfo data would >>>> represent the randomized layout. And that being the case, the >>>> inconvenience would be that the crash session would show the >>>> randomized layout, while the associated source code would show >>>> the original layout. >>>> >>> >>> BTW, I don't have any compiler knowledge before, just from these two >>> days learning, I feel you are right at "vmlinux file's debuginfo data >>> would represent the randomized layout". >>> >>> But when I debug, it seem not like what it should be. I have two file >>> pairs, randomized and non-randomized one. I print some member offset of >>> structure tagged with __randomize_layout after MEMBER_OFFSET_INIT, like >>> this one: >>> >>> (gdb) p offset_table->task_struct_state >>> $1 = 8 >>> (gdb) p offset_table->task_struct_exit_state >>> $2 = 2164 >>> (gdb) p offset_table->task_struct_pid >>> $3 = 2264 >>> (gdb) p offset_table->task_struct_comm >>> $4 = 2744 >>> (gdb) p offset_table->task_struct_next_task >>> $5 = -1 >>> (gdb) p offset_table->task_struct_processor >>> $6 = -1 >>> (gdb) p offset_table->task_struct_p_pptr >>> $7 = -1 >>> (gdb) p offset_table->task_struct_parent >>> $8 = 2288 >>> >>> Under both file pairs, these offset value are the same, so, I think that >>> is why I have the impression that debuginfo has the original structure >>> layout. I guess this is one kind of "MEMBER_OFFSET() no longer work"? >> >> >> It appears that way. A better manner would be to simply run >> gdb on the 2 vmlinux files, i.e., run "gdb vmlinux", and then >> print out one of the required data structures that has the >> "__randomize_layout" compiler annotation, such as the mm_struct: >> >> struct mm_struct { >> struct vm_area_struct *mmap; /* list of VMAs */ >> struct rb_root mm_rb; >> u32 vmacache_seqnum; /* per-thread vmacache */ >> >> ... [ cut ] ... >> >> } __randomize_layout; >> >> In each gdb session, run the command "ptype struct mm_struct", >> and compare the two outputs. If they are the identical, then there >> is a major problem. >> > > I compared the output of "ptype struct uts_namespace"(and also > mm_struct), it seems there does is a major problem, the two outputs are > the same:( > >> A fundamental underpinning of the crash utility is the ability >> to gather correct structure member offsets from the embedded gdb >> module, which gets them from the debuginfo data of the vmlinux file. >> If the structure layout is identical in both the randomized >> and non-randomized vmlinux files, then the crash utility will >> be pretty much useless. >> > > Seems horrible thing happens. > >> I agree with Linus Torvalds with respect to this feature, where in >> the article that you referenced, he says: >> >> Nevertheless, Torvalds is unimpressed by structure randomization, >> calling it "security theater". The fact that distributions need to >> publish the randomization seeds for module-building meant it did >> not provide as big of a security feature as advertised. Torvalds >> however did add: "So it's imnsho a pretty questionable security >> thing. It's likely most useful for one-off 'special secure >> installations' than mass productions. >> >> I have long believed that the constant onslaught of new "security" >> features pushed into the kernel by Kees Cook will eventually kill >> the capability of using the crash utility to debug the kernel. So >> far we've been able to work around or adapt to previous security >> related changes, but this particular feature looks to be a crash >> killer. >> > > Yes, also feels that it is not easy to adapt or work around since the > randomized structure layout info is not reflect in the vmlinux's > debuginfo. I don't know gcc internals, so a blind guess is that it is > done in this way on purpose for security, so attackers won't bother to > seek the random seed, but just using gdb to find out the structure layout. I'm not an expert either, but I feel that this is a gcc bug. If anyone is concerned about security, they needn't publish any debuginfo at all, rather than giving useless debuginfo.

Have you tried reporting this behaviour upstream as abug?

Petr T .