From: Rusty Russell <rusty@rustcorp.com.au>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-s390@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"x86@kernel.org" <x86@kernel.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
mpe@ellerman.id.au, Michal Marek <mmarek@suse.cz>
Subject: Re: [PATCH 0/4] support for text-relative kallsyms table
Date: Wed, 27 Jan 2016 14:16:41 +1030 [thread overview]
Message-ID: <87a8nrvg4e.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAKv+Gu8Pzjt3e_CH0xiCqTk8b6kWV=7Wbiy2YsX99g0SQTW8Tg@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 21 January 2016 at 07:45, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 21 January 2016 at 06:10, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>>> This implements text-relative kallsyms address tables. This was developed
>>>> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
>>>> I think it may be beneficial to other architectures as well, so I am
>>>> presenting it as a separate series.
>>>
>>> Nice work!
>>>
>>
>> Thanks
>>
>>> AFAICT this should work for every arch, as long as they start with _text
>>> (esp: data and init must be > _text). In addition, it's not harmful on
>>> 32 bit archs.
>>>
>>> IOW, I'd like to turn it on for everyone and discard some code. But
>>> it's easier to roll in like you've done first.
>>>
>>> Should we enable it by default for every arch for now, and see what
>>> happens?
>>>
>>
>> As you say, this only works if every symbol >= _text, which is
>> obviously not the case per the conditional in scripts/kallsyms.c,
>> which emits _text + n or _text - n depending on whether the symbol
>> precedes or follows _text. The git log tells me for which arch this
>> was originally implemented, but it does not tell me which other archs
>> have come to rely on it in the meantime.
>>
>> On top of that, ia64 fails to build with this option, since it has
>> some whitelisted absolute symbols that look suspiciously like they
>> could be emitted as _text relative (and it does not even matter in the
>> absence of CONFIG_RELOCATABLE on ia64, afaict) but I don't know
>> whether we can just override their types as T, since it would also
>> change the type in the contents of /proc/kallsyms. So some guidance
>> would be appreciated here.
>>
>
> Digging a little deeper, it appears that it would be non-trivial to
> port this to ia64:
>
> ...
> a000000000040720 A __kernel_syscall_via_break
> a000000000040740 A __kernel_sigtramp
> a000000000040a00 A __kernel_syscall_via_epc
> a000000100000000 T ia64_ivt
> a000000100000000 T __start_ivt_text
> a000000100000000 T _stext
> a000000100000000 T _text
> ...
>
> The top three symbols are the absolute symbols that are explicitly
> whitelisted by scripts/kallsyms.c, and they are too far from 0 and too
> far from _text to be representable in 32 bits
How annoying. OK, until ia64 is removed, we'll leave the option.
Thanks,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-s390@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"x86\@kernel.org" <x86@kernel.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, "hpa\@zytor.com" <hpa@zytor.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
mpe@ellerman.id.au, Michal Marek <mmarek@suse.cz>
Subject: Re: [PATCH 0/4] support for text-relative kallsyms table
Date: Wed, 27 Jan 2016 14:16:41 +1030 [thread overview]
Message-ID: <87a8nrvg4e.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAKv+Gu8Pzjt3e_CH0xiCqTk8b6kWV=7Wbiy2YsX99g0SQTW8Tg@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 21 January 2016 at 07:45, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 21 January 2016 at 06:10, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>>> This implements text-relative kallsyms address tables. This was developed
>>>> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
>>>> I think it may be beneficial to other architectures as well, so I am
>>>> presenting it as a separate series.
>>>
>>> Nice work!
>>>
>>
>> Thanks
>>
>>> AFAICT this should work for every arch, as long as they start with _text
>>> (esp: data and init must be > _text). In addition, it's not harmful on
>>> 32 bit archs.
>>>
>>> IOW, I'd like to turn it on for everyone and discard some code. But
>>> it's easier to roll in like you've done first.
>>>
>>> Should we enable it by default for every arch for now, and see what
>>> happens?
>>>
>>
>> As you say, this only works if every symbol >= _text, which is
>> obviously not the case per the conditional in scripts/kallsyms.c,
>> which emits _text + n or _text - n depending on whether the symbol
>> precedes or follows _text. The git log tells me for which arch this
>> was originally implemented, but it does not tell me which other archs
>> have come to rely on it in the meantime.
>>
>> On top of that, ia64 fails to build with this option, since it has
>> some whitelisted absolute symbols that look suspiciously like they
>> could be emitted as _text relative (and it does not even matter in the
>> absence of CONFIG_RELOCATABLE on ia64, afaict) but I don't know
>> whether we can just override their types as T, since it would also
>> change the type in the contents of /proc/kallsyms. So some guidance
>> would be appreciated here.
>>
>
> Digging a little deeper, it appears that it would be non-trivial to
> port this to ia64:
>
> ...
> a000000000040720 A __kernel_syscall_via_break
> a000000000040740 A __kernel_sigtramp
> a000000000040a00 A __kernel_syscall_via_epc
> a000000100000000 T ia64_ivt
> a000000100000000 T __start_ivt_text
> a000000100000000 T _stext
> a000000100000000 T _text
> ...
>
> The top three symbols are the absolute symbols that are explicitly
> whitelisted by scripts/kallsyms.c, and they are too far from 0 and too
> far from _text to be representable in 32 bits
How annoying. OK, until ia64 is removed, we'll leave the option.
Thanks,
Rusty.
next prev parent reply other threads:[~2016-01-27 3:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 9:05 [PATCH 0/4] support for text-relative kallsyms table Ard Biesheuvel
2016-01-20 9:05 ` [PATCH 1/4] kallsyms: add support for relative offsets in kallsyms address table Ard Biesheuvel
2016-01-20 19:13 ` Kees Cook
2016-01-20 9:05 ` [PATCH 2/4] powerpc: enable text relative kallsyms for ppc64 Ard Biesheuvel
2016-01-21 4:01 ` Michael Ellerman
2016-01-20 9:05 ` [PATCH 3/4] s390: enable text relative kallsyms for 64-bit targets Ard Biesheuvel
2016-01-20 9:43 ` Heiko Carstens
2016-01-20 10:04 ` Ard Biesheuvel
2016-01-20 10:17 ` Heiko Carstens
2016-01-20 10:18 ` Ard Biesheuvel
2016-01-20 9:05 ` [PATCH 4/4] x86_64: " Ard Biesheuvel
2016-01-20 19:12 ` Kees Cook
2016-01-20 10:33 ` [PATCH 0/4] support for text-relative kallsyms table Ingo Molnar
2016-01-20 11:50 ` Arnd Bergmann
2016-01-21 5:10 ` Rusty Russell
2016-01-21 5:10 ` Rusty Russell
2016-01-21 6:45 ` Ard Biesheuvel
2016-01-21 8:32 ` Ard Biesheuvel
2016-01-27 3:46 ` Rusty Russell [this message]
2016-01-27 3:46 ` Rusty Russell
2016-02-08 17:19 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8nrvg4e.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=benh@kernel.crashing.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=mmarek@suse.cz \
--cc=mpe@ellerman.id.au \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.