* 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.
But only reporting the random offset with every raw oops and stack
dump would lead to equivalent information as well. We can tweak this
as we go, it's not like these details are ABIs - I just still think
that the KASLR feature isn't nearly as utility oriented as it should
be.
Thanks,
Ingo
--
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/
