Am 27.01.2014 08:38, schrieb Ingo Molnar: > > * H. Peter Anvin <h...@zytor.com> wrote: > >> On 01/26/2014 10:49 PM, Richard Weinberger wrote: >>>> >>>> No, because that information is available to user space unless we panic. >>> >>> Didn't you mean non-root? >>> I thought one has to set dmesg_restrict anyways if kASLR is used. >>> >>> And isn't the offset available to perf too? >>> Of course only for root, but still user space. >>> >> >> For certain system security levels one want to protect even from a >> rogue root. In those cases, leaking that information via dmesg and >> perf isn't going to work, either. >> >> With lower security settings, by all means... > > The 'no' was categorical and unconditional though, so is the right > answer perhaps something more along the lines of: > > 'Yes, the random offset can be reported in an oops, as long as > high security setups can turn off the reporting of the offset, > in their idealistic attempt to protect the system against root.' > > ? > > I also still think that in addition to reporting the offset, > automatically 'un-randomizing' the oopses and warnings would be useful > as well: with a clear to recognize indicator used for every value > unrandomized, such as capitalizing their first hexa digit. > > Let me show a mockup of how I think it could work: > > raw 64-bit original: > > [ 246.085174] <IRQ> [<ffffffff8264fbf6>] dump_stack+0x46/0x58 > [ 246.098352] [<ffffffff82054fb6>] warn_slowpath_fmt+0x46/0x50 > [ 246.104786] [<ffffffff825710d6>] dev_watchdog+0x246/0x250 > [ 246.110923] [<ffffffff82570e90>] ? > dev_deactivate_queue.constprop.31+0x80/0x80 > [ 246.119097] [<ffffffff8206092a>] call_timer_fn+0x3a/0x110 > [ 246.125224] [<ffffffff8206280f>] ? update_process_times+0x6f/0x80 > > 64-bit un-randomized: > > [ 246.085174] <IRQ> [<FFFFFFFF8164fbf6>] dump_stack+0x46/0x58 > [ 246.091633] [<FFFFFFFF81054ecc>] warn_slowpath_common+0x8c/0xc0 > [ 246.098352] [<FFFFFFFF81054fb6>] warn_slowpath_fmt+0x46/0x50 > [ 246.104786] [<FFFFFFFF815710d6>] dev_watchdog+0x246/0x250 > [ 246.110923] [<FFFFFFFF81570e90>] ? > dev_deactivate_queue.constprop.31+0x80/0x80 > [ 246.119097] [<FFFFFFFF8106092a>] call_timer_fn+0x3a/0x110 > [ 246.125224] [<FFFFFFFF8106280f>] ? update_process_times+0x6f/0x80 > > Note how the hex values of unrandomized kernel text start with capital > letters, and how their values match up System.map and vmlinux symbol > values. > > raw 32-bit randomized: > > [ 39.054098] [<c20ded55>] ? __jump_label_update+0x45/0x60 > [ 39.064852] [<c2057aa2>] ? queue_work_on+0x32/0x70 > [ 39.074570] [<c20085b1>] ? mark_tsc_unstable+0x21/0x60 > [ 39.084980] [<c2f03af6>] ? tsc_init+0x326/0x344 > [ 39.094175] [<c2eff9c5>] ? start_kernel+0x2c7/0x356 > > 32-bit un-randomized: > > [ 39.054098] [<C10ded55>] ? __jump_label_update+0x45/0x60 > [ 39.064852] [<C1057aa2>] ? queue_work_on+0x32/0x70 > [ 39.074570] [<C10085b1>] ? mark_tsc_unstable+0x21/0x60 > [ 39.084980] [<C1f03af6>] ? tsc_init+0x326/0x344 > [ 39.094175] [<C1eff9c5>] ? start_kernel+0x2c7/0x356 > > This looks eminently useful to me, I could plug those hexa values into > gdb straight away to look up a symbol instead of having to subtract > the random offset first. > > This would do 99% of the unrandomizing job for the user/developer (and > not the least, for tooling), without obfuscating oopses as it would be > clear on which values the unrandomizing was performed, without losing > information.
I like this idea. Hopefully nothing breaks if the mix lower and upper case hex numbers. =) If so we could still inject a line like "[<fffffffffffffffe>] __unrandomize_addr+0x0/0x0" into the trace to mark a an un-randomized one. Or a <UN-RANDOM> like <IRQ> on x86_64... Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/