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
| ||
|
Date: Mon, 28 Feb 2022 00:27:09 +0100 From: "Jason A. Donenfeld" <Jason@...c4.com> To: Alexander Graf <graf@...zon.com> Cc: Len Brown <lenb@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Ard Biesheuvel <ardb@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Re: [PATCH v5 2/3] ACPI: allow longer device IDs Hey again, On Sun, Feb 27, 2022 at 1:43 PM Jason A. Donenfeld <Jason@...c4.com> wrote: > > Hi Alex, > > On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote: > > > To allow device drivers to match identifiers that exceed the 9 byte > > > limit, this simply ups the length to 16, just like it was before the > > > aforementioned commit. Empirical testing indicates that this > > > > > > This is only true for 64bit systems where padding automatically bloated > > to 9 byte array to 16. I still believe the patch is fine as it is, but > > there will be minor .rodata overhead on 32bit targets which you may want > > to quantify in the patch description. > > Good point. So I just tried this out with a 32-bit i686 kernel and the > results are the same again for the size of vmlinux. I then ran `objdump > --headers` and looked at the size of the .rodata section, where it's > also the same. I'm not quite sure what to make of this, as it's not what > I was expecting, but I think I tested it right. So maybe we're lucky > here? I tried a little harder to get _some_ difference on 32-bit, and managed to get one by doing i386_defconfig and then switching off modules to make all M into Y, and then compared sizes: vmlinux: 25590780 -> 25598972, so a 0.032% increase. bzImage: 8698944 -> 8699424, so a 0.0055% increase. So it does increase, ever so slightly, but a) on 32-bit, and b) a super, super tiny amount. In other words, I still think this patch is very much a-okay. But very eager to hear from Rafael on the approach. Jason
Powered by blists - more mailing lists