[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKv+Gu84LmMpGoA2Cs4_UJJZZwTWAyZ+u94QnwNd7=7J8KPoTw@mail.gmail.com>
Date: Mon, 8 Feb 2016 18:19:38 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Rusty Russell <rusty@...tcorp.com.au>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Kees Cook <keescook@...omium.org>,
Ingo Molnar <mingo@...nel.org>,
"hpa@...or.com" <hpa@...or.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 0/4] support for text-relative kallsyms table
On 21 January 2016 at 06:10, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Ard Biesheuvel <ard.biesheuvel@...aro.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!
>
> 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?
>
OK, that's what I did, and this is what happened:
Initially, some breakage on sparc32 and !smp x86_64, as reported by
Guenter. After fixing that, all looked fine until Andrew picked up my
patch the other day to actually abort the build when kallsyms fails
(where before that, it would emit the warning but continue with the
build and produce a broken binary). Now, I have new reports for
Blackfin and Tile-GX as well, neither of which I can build myself
easily, since no toolchains for them are available on
https://www.kernel.org/pub/tools/crosstool/
SInce --absolute-percpu is only used by x86_64, I can fix the 32-bit
case generically by using the full 32-bits for relative symbols, and
only split the kallsyms address space into 2 GB of absolute values and
2 GB of relative values if --absolute-percpu is in effect. For the
Tile-GX case, the only thing I can propose is to disable this feature
for that architecture, and perhaps someone with a clue can figure out
whether the symbols are in fact laid out that sparsely, or something
else is going on.
I will send a v5 of my 3 piece kallsyms series momentarily. The patch
that forces the build failure on kallsyms failure can remain as is
(http://ozlabs.org/~akpm/mmotm/broken-out/scripts-link-vmlinuxsh-force-error-on-kallsyms-failure.patch)
Thanks,
Ard.
Powered by blists - more mailing lists