[PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
Marc Zyngier
maz at kernel.org
Mon Jan 25 09:28:47 EST 2021
On 2021-01-25 14:19, Ard Biesheuvel wrote:
> On Mon, 25 Jan 2021 at 14:54, Marc Zyngier <maz at kernel.org> wrote:
>>
>> On 2021-01-25 12:54, Ard Biesheuvel wrote:
[...]
>> > This struct now takes up
>> > - ~100 bytes for the characters themselves (which btw are not emitted
>> > into __initdata or __initconst)
>> > - 6x8 bytes for the char pointers
>> > - 6x24 bytes for the RELA relocations that annotate these pointers as
>> > quantities that need to be relocated at boot (on a kernel built with
>> > KASLR)
>> >
>> > I know it's only a drop in the ocean, but in this case, where the
>> > struct is statically declared and defined only once, and in the same
>> > place, we could easily turn this into
>> >
>> > static const struct {
>> > char alias[24];
>> > char param[20];
>> > };
>> >
>> > and get rid of all the overhead. The only slightly annoying thing is
>> > that the array sizes need to be kept in sync with the largest instance
>> > appearing in the array, but this is easy when the struct type is
>> > declared in the same place where its only instance is defined.
>>
>> Fair enough. I personally find the result butt-ugly, but I agree
>> that it certainly saves some memory. Does the following work for
>> you? I can even give symbolic names to the various constants (how
>> generous of me! ;-).
>>
>
> To be honest, I was anticipating more of a discussion, but this looks
> reasonable to me.
It looked like a reasonable ask: all the strings are completely useless
once the kernel has booted, and I'm the first to moan that I can't boot
an arm64 kernel with less than 60MB of RAM (OK, it's a pretty bloated
kernel...).
> Does 'char feature[80];' really need 80 bytes though?
It really needs 75 bytes, because of this:
{ "arm64.nopauth",
"id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
"id_aa64isar1.api=0 id_aa64isar1.apa=0" },
80 is a round enough number.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel
mailing list