From: Daniel Micay <danielmicay@gmail.com>
To: kernel-hardening@lists.openwall.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant
Date: Thu, 15 Dec 2016 19:05:20 -0500 [thread overview]
Message-ID: <1481846720.1054.1.camel@gmail.com> (raw)
In-Reply-To: <20161215211807.GA13393@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 4503 bytes --]
> Thanks for the explanation. I don't think we need to worry about
> merging these strings, but I'll keep it in mind.
>
> However, the "folklore" of the kernel was to never do:
> char *foo = "bar";
> but instead do:
> char foo[] = "bar";
> to save on the extra variable that the former creates. Is that no
> longer the case and we really should be using '*' to allow gcc to be
> smarter about optimizations?
>
> > The 'const' qualifier for pointers doesn't really do anything, it's
> > when
> > it's used on the variable (after the pointer) that it can do more
> > than
> > acting as a programming guide.
>
> Many thanks for the explanations,
>
> greg k-h
Can see what the compiler has to work with pretty easily from LLVM IR:
char *const constant_string_constant = "string";
char *const constant_string_constant2 = "string";
char *non_constant_string_constant = "string";
char *non_constant_string_constant2 = "string";
char non_constant_string_array[] = "string";
char non_constant_string_array2[] = "string";
const char constant_string_array[] = "string";
const char constant_string_array2[] = "string";
Becomes:
@.str = private unnamed_addr constant [7 x i8] c"string\00", align 1
@constant_string_constant = constant i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0), align 8
@constant_string_constant2 = constant i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0), align 8
@non_constant_string_constant = global i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0), align 8
@non_constant_string_constant2 = global i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0), align 8
@non_constant_string_array = global [7 x i8] c"string\00", align 1
@non_constant_string_array2 = global [7 x i8] c"string\00", align 1
@constant_string_array = constant [7 x i8] c"string\00", align 1
@constant_string_array2 = constant [7 x i8] c"string\00", align 1
And with optimization:
@constant_string_constant = local_unnamed_addr constant i8* getelementptr inbounds ([7 x i8], [7 x i8]* @constant_string_array, i64 0, i64 0), align 8
@constant_string_constant2 = local_unnamed_addr constant i8* getelementptr inbounds ([7 x i8], [7 x i8]* @constant_string_array, i64 0, i64 0), align 8
@non_constant_string_constant = local_unnamed_addr global i8* getelementptr inbounds ([7 x i8], [7 x i8]* @constant_string_array, i64 0, i64 0), align 8
@non_constant_string_constant2 = local_unnamed_addr global i8* getelementptr inbounds ([7 x i8], [7 x i8]* @constant_string_array, i64 0, i64 0), align 8
@non_constant_string_array = local_unnamed_addr global [7 x i8] c"string\00", align 1
@non_constant_string_array2 = local_unnamed_addr global [7 x i8] c"string\00", align 1
@constant_string_array = local_unnamed_addr constant [7 x i8] c"string\00", align 1
@constant_string_array2 = local_unnamed_addr constant [7 x i8] c"string\00", align 1
If they're static though, the compiler can see that nothing takes the
address (local_unnamed_addr == unnamed_addr if it's internal) so it
doesn't need separate variables anyway:
static char *const constant_string_constant = "string";
static char *const constant_string_constant2 = "string";
char *foo() {
return constant_string_constant;
}
char *bar() {
return constant_string_constant2;
}
Becomes (with optimization):
@.str = private unnamed_addr constant [7 x i8] c"string\00", align 1
; Function Attrs: norecurse nounwind readnone uwtable
define i8* @foo() local_unnamed_addr #0 {
ret i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i64 0, i64 0)
}
; Function Attrs: norecurse nounwind readnone uwtable
define i8* @bar() local_unnamed_addr #0 {
ret i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i64 0, i64 0)
}
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]
next prev parent reply other threads:[~2016-12-16 0:05 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 18:50 [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe" Greg KH
2016-12-14 18:50 ` Greg KH
2016-12-14 18:50 ` [kernel-hardening] [PATCH 1/4] kmod: make usermodehelper path a const string Greg KH
2016-12-14 18:50 ` Greg KH
2016-12-14 18:50 ` [kernel-hardening] [PATCH 2/4] drbd: rename "usermode_helper" to "drbd_usermode_helper" Greg KH
2016-12-14 18:50 ` Greg KH
2016-12-14 18:50 ` [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant Greg KH
2016-12-14 18:50 ` Greg KH
2016-12-14 19:11 ` [kernel-hardening] " Greg KH
2016-12-14 20:29 ` Rich Felker
2016-12-14 20:54 ` Greg KH
2016-12-15 17:54 ` Greg KH
2016-12-15 20:51 ` Daniel Micay
2016-12-15 21:18 ` Greg KH
2016-12-16 0:05 ` Daniel Micay [this message]
2016-12-16 0:14 ` Daniel Micay
2016-12-14 18:51 ` [kernel-hardening] [RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER Greg KH
2016-12-14 18:51 ` Greg KH
2016-12-14 20:31 ` [kernel-hardening] " Kees Cook
2016-12-14 20:31 ` Kees Cook
2016-12-14 20:57 ` [kernel-hardening] " Greg KH
2016-12-14 20:57 ` Greg KH
2016-12-14 19:25 ` [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe" Mark Rutland
2016-12-14 20:16 ` Kees Cook
2016-12-14 21:28 ` Jason A. Donenfeld
2016-12-14 23:16 ` Greg Kroah-Hartman
2016-12-16 1:02 ` [kernel-hardening] " NeilBrown
2016-12-16 1:02 ` NeilBrown
2016-12-16 12:49 ` [kernel-hardening] " Greg KH
2016-12-16 12:49 ` Greg KH
2016-12-19 13:34 ` [kernel-hardening] " Jiri Kosina
2016-12-19 13:34 ` Jiri Kosina
2016-12-20 9:27 ` [kernel-hardening] " Greg KH
2016-12-20 9:27 ` Greg KH
2016-12-20 10:27 ` [kernel-hardening] " Jiri Kosina
2016-12-20 10:27 ` Jiri Kosina
2016-12-20 10:31 ` [kernel-hardening] " Jiri Kosina
2016-12-20 10:31 ` Jiri Kosina
2016-12-20 10:48 ` [kernel-hardening] " Greg KH
2016-12-20 10:48 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1481846720.1054.1.camel@gmail.com \
--to=danielmicay@gmail.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.