From: Vasiliy Kulikov <segoon@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] GNU_STACK policy problem
Date: Mon, 22 Aug 2011 13:34:05 +0400 [thread overview]
Message-ID: <20110822093405.GA2450@albatros> (raw)
In-Reply-To: <20110723153751.GB11156@openwall.com>
Solar,
On Sat, Jul 23, 2011 at 19:37 +0400, Solar Designer wrote:
> > One solution I see is somehow passing this information (GNU_STACK
> > handling policy for 2 cases) at the task creation time. Something like
> > VDSO symbol (2) or auxv entry (3). VDSO case is complicated as IIRC now
> > it is global to the kernel and is not per pid namespace (I recall a
> > problem in OpenVZ kernel when kernel version symbol was globally removed
> > to fool some pid namespaces expecting new kernel). auxv is complicated
> > as it is ELF ABI changing :-(
>
> I like the auxv approach.
>
> I don't know who is the central authority to allocate new AT_* values or
> AT_FLAGS bits (perhaps for Linux only) - do you? My guess is that if we
> get a couple of extra AT_FLAGS bits accepted into mainline kernels, that
> will be it.
Looking into ELF documentation:
In MIPS, SPARC no AT_FLAGS bits are used currently. And "bits under the
0xff000000 mask are reserved for system semantics."
In IA-32 and PPC no bits are used. No "system" flags are mentioned.
I didn't find any definition of "system semantics", I guess it means any
non-standard usage on local system. Probably we should use these bits.
For now I used two low order bits.
$ LD_SHOW_AUXV=1 /bin/true | grep FLAGS
AT_FLAGS: 0x0
# sysctl kernel.execstack_mode=7
kernel.execstack_mode = 7
$ LD_SHOW_AUXV=1 /bin/true | grep FLAGS
AT_FLAGS: 0x3
The changes relative to the previous patch:
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 64330e5..17aad10 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -134,6 +134,20 @@ static int padzero(unsigned long elf_bss)
#define ELF_BASE_PLATFORM NULL
#endif
+static
+elf_addr_t get_at_flags(void)
+{
+ enum execstack_mode stack = current->nsproxy->pid_ns->execstack_mode;
+ elf_addr_t flags = 0;
+
+ if (stack & GNU_STACK_X_FORCE_NX)
+ flags |= 1;
+ if (stack & NO_GNU_STACK_FORCE_NX)
+ flags |= 2;
+
+ return flags;
+}
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -155,6 +169,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
int ei_index = 0;
const struct cred *cred = current_cred();
struct vm_area_struct *vma;
+ elf_addr_t at_flags = get_at_flags();
/*
* In some cases (e.g. Hyper-Threading), we want to avoid L1
@@ -226,7 +241,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
NEW_AUX_ENT(AT_PHNUM, exec->e_phnum);
NEW_AUX_ENT(AT_BASE, interp_load_addr);
- NEW_AUX_ENT(AT_FLAGS, 0);
+ NEW_AUX_ENT(AT_FLAGS, at_flags);
NEW_AUX_ENT(AT_ENTRY, exec->e_entry);
NEW_AUX_ENT(AT_UID, cred->uid);
NEW_AUX_ENT(AT_EUID, cred->euid);
--
Vasiliy
next prev parent reply other threads:[~2011-08-22 9:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 19:48 [kernel-hardening] GNU_STACK policy problem Vasiliy Kulikov
2011-07-21 13:03 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-23 15:06 ` [kernel-hardening] " Solar Designer
2011-07-24 8:39 ` Vasiliy Kulikov
2011-07-24 14:06 ` Solar Designer
2011-07-26 12:07 ` Vasiliy Kulikov
2011-07-23 15:37 ` Solar Designer
2011-08-22 9:34 ` Vasiliy Kulikov [this message]
2011-08-22 9:41 ` Solar Designer
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=20110822093405.GA2450@albatros \
--to=segoon@openwall.com \
--cc=kernel-hardening@lists.openwall.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox