On Sun, Oct 26, 2014 at 11:11 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On x86 we have discussed to combine thread_info and task_struct into a single allocation with a percpu variable lining pointng at it. Is that better than just gradually eliminating all the members of thread_info? Anyway, ftrace is the only user of ti->task on x86, so it's not a very juicy target. --Andy > > On October 26, 2014 11:09:39 AM PDT, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >>On Sun, Oct 26, 2014 at 10:36:45AM -0700, Andy Lutomirski wrote: >> >>> I never said it was the *only* juicy target, but we can fix the rest, >>> too. Also, I suspect that overwriting task could be harder to >>> exploit. First, you need to avoid crashing, and second, on systems >>> with SMAP or similar protection, you need to make task point >>somewhere >>> that contains a useful exploit payload. >>> >>> We could probably get rid of thread_info's task pointer on x86, too >>-- >>> it's not used by get_current() any more. >> >>Huh? If you can overwrite that pointer, you can bloody well overwrite >>->task itself, making it point into the overwritten part of stack right >>next to thread_info. >> >>Again, on most of the architectures the _only_ way to reach task_struct >>is via thread_info: >> * everything that uses asm-generic/current.h - arm, arm64, blackfin, >>c6x, hexagon, metag, mips, openrisc, sh, um, unicore32 >> * everything that should be using it - alpha, avr32, cris, m32r, >>parisc, score, tile. These guys can simply add generic-y += current.h >>into their asm/Kbuild and remove asm/current.h. >> * nearly the same situation - xtensa (there's an asm variant of >>the same thing + copy of asm-generic/current.h for C) >> * sparc32 >> * m68k-noMMU >> * mn10300-SMP >> >>It's a strong majority. Check arch/*/asm/current.h and see for >>yourself. > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting. -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html