On Thu, 25 Jan 2018 16:37:01 +0800 Cao jin <caoj.fnst@xxxxxxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
