libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Checking Local Memory Accesses


From: Masatake YAMATO
Subject: Re: [Libunwind-devel] Checking Local Memory Accesses
Date: Tue, 19 Nov 2013 17:42:47 +0900 (JST)

Hi, 

It seems that we are working on similar area in different purposes:)

I have some comments.

  * Once _U_map_list is initialized the process cannot update it.
    If the process calls a system call like mmap which updates the
    memory mapping, the value pointed by _U_map_list is invalid.
    Is it o.k. in your use-case?

  * Is the linked list+linear search is better than array+bsearch?
    (I used array+bsearch in my patch.)
  
I'm not sure whether my patch will be included into libunwind official
source tree or not. However, I think my patch can simplify your patch.

Masatake YAMATO

> While working with the libunwind library on Android, there are some cases
> that crash the library. Specifically, when unwinding the stack of the local
> process, if the unwind data is not quite right, you might wind up with a
> bad pc (such as having a value of 0xe). Unfortunately, the code will gladly
> try to access this memory and then the code crashes. Any attempt to read
> memory that is unreadable or write memory that is unwritable will cause
> this type of crash.
> 
> I have a proof of concept patch to demonstrate a way to fix this.
> Essentially the patch would use the linux /proc/self/maps data to figure
> out if a particular address is readable/writable then return an error for
> cases where a crash is likely. I only implemented this for x86_64 on linux
> based systems.
> 
> For the final version, I would add a version of the map generation
> functions which always returns true for the other os types and add the
> check code to all of the memory access routines for all of the different
> supported architectures.
> 
> Does this seem like a valid approach?
> 
> Christopher Ferris
> (address@hidden)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]