(un)desired behaviour of memory protection - or is it gcc?

classic Classic list List threaded Threaded
6 messages Options
viq
Reply | Threaded
Open this post in threaded view
|

(un)desired behaviour of memory protection - or is it gcc?

viq
Or at least unexpected ;)
I attach the program i was working on yes, very primitive, and obviously wrong
- array, line 31. And that array is exactly what got me surprised. It should
be char perms[11], and as expected, on both linux and OpenBSD with that value
it works fine. When it's [10], on linux the previous line (type) gives
garbage. On OpenBSD it still works fine. When it is set to 9, as now, on
linux the programs exits with memory protection fault. On OpenBSD it still
works fine.

...ok, now i don't know what to think of it. The described behaviour was
observed on a Fedora Core 4 system (gcc 4, IIRC) - and right now i tried it
on a different linux system, with gcc 3.4 installed - and it works fine there
as well, with [9] set. Any idea what's causing this?

Thanks in advance, and sorry for a lame-ish question

--
viq


----------------------------------------------------------------------
Znow swieta?
Kliknij po kredyt gotowkowy i zostan Prawdziwym Sw. Mikolajem!
>>> http://link.interia.pl/f18e7

[demime 1.01d removed an attachment of type text/x-csrc which had a name of fileinfo.c]

Reply | Threaded
Open this post in threaded view
|

Re: (un)desired behaviour of memory protection - or is it gcc?

Darrin Chandler
viq wrote:

>I attach the program i was working on yes, very primitive, and obviously wrong
>  
>

Attachments get stripped on this list (thankfully). If you've reduced it
to be very small then post it inline with the message, otherwise include
a link to your code.

--
Darrin Chandler
[hidden email]
http://www.stilyagin.com/

viq
Reply | Threaded
Open this post in threaded view
|

Re: (un)desired behaviour of memory protection - or is it gcc?

viq
On Saturday 03 December 2005 21:28, Darrin Chandler wrote:
> viq wrote:
> >I attach the program i was working on yes, very primitive, and obviously
> > wrong
>
> Attachments get stripped on this list (thankfully). If you've reduced it
> to be very small then post it inline with the message, otherwise include
> a link to your code.

ah, yes. 100 lines, so now it resides on
http://www.rafb.net/paste/results/YRKPfI79.html

----------------------------------------------------------------------
Znow swieta?
Kliknij po kredyt gotowkowy i zostan Prawdziwym Sw. Mikolajem!
>>> http://link.interia.pl/f18e7

Reply | Threaded
Open this post in threaded view
|

Re: (un)desired behaviour of memory protection - or is it gcc?

Miod Vallat
In reply to this post by viq
> ...ok, now i don't know what to think of it. The described behaviour was
> observed on a Fedora Core 4 system (gcc 4, IIRC) - and right now i tried it
> on a different linux system, with gcc 3.4 installed - and it works fine there
> as well, with [9] set. Any idea what's causing this?

The compiler in OpenBSD will reorder local variables. In your case,
``type'' is below ``perms'' (unlike the Linux compiler), and due to
alignment, you can be lucky enough to overflow perms a bit without this
causing problems.

Miod

viq
Reply | Threaded
Open this post in threaded view
|

Re: (un)desired behaviour of memory protection - or is it gcc?

viq
On Saturday 03 December 2005 22:13, Miod Vallat wrote:

> > ...ok, now i don't know what to think of it. The described behaviour was
> > observed on a Fedora Core 4 system (gcc 4, IIRC) - and right now i tried
> > it on a different linux system, with gcc 3.4 installed - and it works
> > fine there as well, with [9] set. Any idea what's causing this?
>
> The compiler in OpenBSD will reorder local variables. In your case,
> ``type'' is below ``perms'' (unlike the Linux compiler), and due to
> alignment, you can be lucky enough to overflow perms a bit without this
> causing problems.
>
> Miod

Makes sense, I guess. But shouldn't the new memory protection stuff disallow
even that little bit?

--
viq

----------------------------------------------------------------------
Znow swieta?
Kliknij po kredyt gotowkowy i zostan Prawdziwym Sw. Mikolajem!
>>> http://link.interia.pl/f18e7

Reply | Threaded
Open this post in threaded view
|

Re: (un)desired behaviour of memory protection - or is it gcc?

Gilles Chehade
viq wrote:

>On Saturday 03 December 2005 22:13, Miod Vallat wrote:
>  
>
>>>...ok, now i don't know what to think of it. The described behaviour was
>>>observed on a Fedora Core 4 system (gcc 4, IIRC) - and right now i tried
>>>it on a different linux system, with gcc 3.4 installed - and it works
>>>fine there as well, with [9] set. Any idea what's causing this?
>>>      
>>>
>>The compiler in OpenBSD will reorder local variables. In your case,
>>``type'' is below ``perms'' (unlike the Linux compiler), and due to
>>alignment, you can be lucky enough to overflow perms a bit without this
>>causing problems.
>>
>>Miod
>>    
>>
>
>Makes sense, I guess. But shouldn't the new memory protection stuff disallow
>even that little bit?
>
>  
>
nope, the new "memory protection stuff" (c) does not deal with that :-)
local variables are allocated on the stack while the new memory
protection stuff (c) ensures that heap
allocated memory is used in a sane way.

man alloca, man brk (sbrk), man malloc, man mmap
as the man pages explain, some of these are not to be used anymore, but
they can help you google
for more information on how things work and particularly what is the
difference between local
variables and dynamically allocated memory.

++ veins

nb. the new memory protection stuff (c) helped me spot bugs in code that
ran "perfectly" for years on
      all kind of systems/architectures. As soon as i ran a project
linked with my
      "working-in-a-so-wonderful-way" lib on an OpenBSD 3.8, a segfault
occurred and caused me to fix
      some use-after-free's that i would have never found by reading the
code. /me is amazed and just can't
      get over it ;-)