為什麼mmap size跟root有關系?

http://groups.google.com/group/android-kernel/browse_thread/thread/497ba1a48c3cd710

原因在這
http://lwn.net/Articles/342330/
http://xorl.wordpress.com/2009/08/18/cve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference/
http://www.securityfocus.com/archive/1/archive/1/505751/100/0/threaded

第二個link http://xorl.wordpress.com/2009/08/18/cve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference/

有講到三個hack

http://go2.wordpress.com/?id=725X1342&site=xorl.wordpress.com&url=http%3A%2F%2Fwww.grsecurity.net%2F~spender%2Fwunderbar_emporium.tgz&sref=http%3A%2F%2Fxorl.wordpress.com%2F2009%2F08%2F18%2Fcve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference%2F
這用了
oxff
0x25

0xff 0x25其實就是jmp的opcode
找個例子 objdump -D 就看出來了

http://go2.wordpress.com/?id=725X1342&site=xorl.wordpress.com&url=http%3A%2F%2Fwww.frasunek.com%2Fproto_ops.tgz&sref=http%3A%2F%2Fxorl.wordpress.com%2F2009%2F08%2F18%2Fcve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference%2F

這用了0x90 0xe9

跟最後一個比較簡單的
http://go2.wordpress.com/?id=725X1342&site=xorl.wordpress.com&url=http%3A%2F%2Fmilw0rm.com%2Fsploits%2Fandroid-root-20090816.tar.gz&sref=http%3A%2F%2Fxorl.wordpress.com%2F2009%2F08%2F18%2Fcve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference%2F

opengl from donut to eclair

從donut到eclair,  loading OPENGLES 的方式有點不一樣
there is some difference of loading opengles lib from donut to eclair

check EGL first if you dont know what it is
http://www.khronos.org/egl/

on donut,
software impl for OPENGLES is /system/lib/libagl,
hardware is /system/lib/libhgl

on eclair
software impl is moved to /system/lib/egl/libGLES_android.so
hardware impl is moved to /system/lib/egl/lib{EGL,GLESv1_CM,GLESv2}_"vendor"
for example, on Acer A1 , it's system/lib/egl/libEGL_adreno200.so
                                                                      libGLESv1_CM_adreno200.so
                                                                      libGLESv2_adreno200.so


check framework/base/opengl/libs/EGL/egl.cpp on both branches to see the difference

using JNI in pthread

有人問到為什麼不能在native pthread create出來的 thread "直接" 使用 JNI

在這explain 一下 background

大家知道Thread之間是會shared memory的 (不過stack當然還是自己的)
所以大家寫code 有時會用個global 變數  然後兩三個thread來對這global變數作read/write

不過大概在2000年吧?   ABI (Binary Interface)那時有作一些update 
http://www.sco.com/developers/gabi/2000-07-17/contents.html
主要就是多個TLS - Thread Local Storage
就是讓thread 有自己的global 變數 其他的thread並不會踩到別thread的memory

例如  原本的 int g_is_vm_started;
GCC的話 :  在前面加個 __thread  就變成 thread variable了
__thread int g_is_vm_started;
在這看你自己喜歡的compile怎麼改
http://en.wikipedia.org/wiki/Thread-local_storage

而JNI 也是有用到這東西
所以在call JNI時  VM會去拿TLS裡的pointer  裡面存著vm在這個thread裡的context
如果想看Dalvik的code的話
就是在vm/Jni.c裡的 JNI_ENTER() 這macro裡
( 不過Android上其實並沒有Runtime support TLS
用readelf dump library裡其實並沒有.tdata .tbss的section
上面講的TLS 其實是bionic 裡的pthread 自己作出來的
)


想在pthread create出來的thread裡使用JNI
可以先看這
http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html

還有個在pthread裡的ClassLoader的問題
http://groups.google.com/group/android-ndk/browse_thread/thread/7982fdb5892f79fb

android emulator的cpu

http://groups.google.com/group/android-ndk/browse_thread/thread/b41d13b517abe69d?hl=en



不知道中間Dave Buther講的這段話
On the emulator I suspect it is being (correctly) treated as an
UNDEFINED instruction (the emulator is running as an ARM926 I
believe), under user-mode on an ARM1176 or an ARMv7-a processor it
will still be treated as an UNDEFINED
while in user mode. 


是什麼意思............

gcc的extension

# define PLUGIN_LOG(A, B...) do { LOGI( A , ## B ); } while(0)

看得懂上面那段code嗎
不要以為##是多的

當你的arg只有一個時 PLUGIN_LOG(A) 你就發現它的重要性了

http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

enable native WebKit log

最近一直試著要在native WebKit加log
但就是看不到

最後看到
external/webkit/WebCore/platform/android/ScreenAndroid.cpp
的一段話

35 #undef LOG // FIXME: Still have to do this to get the log to show up
36 #include "utils/Log.h"

照著他的方式來作

媽呀 真的log出現了

原來在WebCore/config.h 會去include
而這裡面也有定義LOG

所以我加的LOG[VDIWE]全都跑到wtf/Assertions.h裡面了
(事實上是空的 因為LOG_DISABLE被設為1了)