linux-kernel - Re: Executability of the stack

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: <1166098747.27217.1018.camel@laptopd505.fenrus.org>
Date:	Thu, 14 Dec 2006 13:19:07 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Franck Pommereau <pommereau@...v-paris12.fr>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Executability of the stack

On Thu, 2006-12-14 at 13:07 +0100, Franck Pommereau wrote:
> >> # grep maps /proc/self/maps
> >> bfce8000-bfcfe000 rw-p bfce8000 00:00 0          [stack]
> > 
> > this shows that the *intent* is to have it non-executable. 
> > Not all x86 processors can enforce this. All modern ones do.
> 
> Mine is quite recent:

> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm

the "nx" shows that if you configure your kernel correctly (enable PAE)
that you indeed have a non-executable capability, which will apply to
the stack (and afaik the heap too)

> > the alternative (showing effective permission) is equally confusing;
> > apps would see permissions they didn't set...
> 
> Indeed, both are confusing (the other way is having permission that you
> do not see). But which one is the most dangerous from a security point
> of view? For me it is believing that you're protected while you're not.

it's debatable what the file means; the maps file shows software
permissions currently not hardware enforced permissions. The "problem"
is that if you show software permissions... it's harder to see the
kernels view (vma's etc). I don't think there's a perfect answer.

It gets even more complex if you have something like execshield in use;
where the stack and heap are non-executable, unless you get a "higher"
executable mapping. In that case, the appearance of such a higher
mapping would change the visual mapping of other mappings. Outright
confusing as well :)
> 
> >> Maybe it comes from sharing source code for 64 bits and 32 bits
> >> architectures but if so, it should be possible (and highly desirable) to
> >> treat 32 bits differently.
> > 
> > it's not a "32 bit" thing, it's an "older processors don't, newer ones
> > do" thing.
> 
> I've read that 64 bit processors have an execute bit at the page level
> while 32 bit ones do not (only at the segment level). I didn't know that
> newer 31 bit CPUs did have this bit.

your cpu has this bit, you just didn't turn it on ;(

> > Can you paste your /proc/cpuinfo file here ? Maybe you have a processor
> > with the capability but just haven't enabled it (either in the bios or
> > in the kernel config)
> 
> I'd be happy to know how to enable it.

enable
CONFIG_HIGHMEM64G=y

and you're all set.


Greetings,
   Arjan van de Ven

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/