linux-kernel - Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <32b49beb87b25303d71fd2f7053c7959@kernel.org>
Date:   Mon, 25 Jan 2021 14:28:47 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        kvmarm <kvmarm@...ts.cs.columbia.edu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        David Brazdil <dbrazdil@...gle.com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Jing Zhang <jingzhangos@...gle.com>,
        Ajay Patil <pajay@....qualcomm.com>,
        Prasad Sodagudi <psodagud@...eaurora.org>,
        Srinivas Ramana <sramana@...eaurora.org>,
        James Morse <james.morse@....com>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early
 cpufeature infrastructure

On 2021-01-25 14:19, Ard Biesheuvel wrote:
> On Mon, 25 Jan 2021 at 14:54, Marc Zyngier <maz@...nel.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...