public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Franck Pommereau <pommereau@univ-paris12.fr>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Executability of the stack
Date: Thu, 14 Dec 2006 13:07:03 +0100	[thread overview]
Message-ID: <45813E67.80709@univ-paris12.fr> (raw)
In-Reply-To: <1166090244.27217.978.camel@laptopd505.fenrus.org>

>> # 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:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz
stepping        : 6
cpu MHz         : 1000.000
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 3996.23

> 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.

>> 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.

> 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.

Thanks for your help.
Franck

  reply	other threads:[~2006-12-14 12:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-14  9:26 Executability of the stack Franck Pommereau
2006-12-14  9:57 ` Arjan van de Ven
2006-12-14 12:07   ` Franck Pommereau [this message]
2006-12-14 12:19     ` Arjan van de Ven
2006-12-14 15:17       ` [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options Theodore Tso
2006-12-14 15:27         ` thunder7
2006-12-14 15:37           ` Theodore Tso
2006-12-14 16:06             ` Arjan van de Ven
2006-12-14 16:11             ` Avi Kivity
2006-12-14 19:58             ` Alistair John Strachan
2006-12-15 17:06           ` Bill Davidsen
2006-12-14 15:52         ` Arjan van de Ven
2006-12-14 12:36   ` Executability of the stack James Courtier-Dutton
     [not found]     ` <1166099950.27217.1024.camel@laptopd505.fenrus.org>
2006-12-14 14:55       ` Franck Pommereau

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=45813E67.80709@univ-paris12.fr \
    --to=pommereau@univ-paris12.fr \
    --cc=arjan@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox