linux-kernel - Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

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: <1481847262.1054.3.camel@gmail.com>
Date:   Thu, 15 Dec 2016 19:14:22 -0500
From:   Daniel Micay <danielmicay@...il.com>
To:     kernel-hardening@...ts.openwall.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper
 binaries constant

> So for statics, I think `static const char *` wins due to allowing
> merging (although it doesn't matter here). For non-statics, you end up
> with extra pointer constants. Those could get removed, but Linux
> doesn't
> have -fvisibility=hidden and I'm not sure how clever linkers are.
> Maybe
> setting up -fvisibility=hidden to work with monolithic non-module-
> enabled builds could actually be realistic. Expect it'd remove a fair
> bit of bloat but not sure how much would need to be marked as non-
> hidden 
> other than the userspace ABI.

-fvisibility=hidden + LTO would be really awesome though, since that
doesn't depend on the cleverness of linkers. So much that could be
ripped out of real world monolithic builds. Kinda getting off-topic now
though. LTO is pretty scary from a security perspective due to how much
worse undefined behavior that was previously harmless can get.
Download attachment "signature.asc" of type "application/pgp-signature" (867 bytes)