Use ASAN without proc access in system init process #1358
Comments
|
It looks like it is working with GCC 10.2: I think this fixed the problem: google/llvm-propeller@15b71ea |
|
This is the more likely fix:
https://reviews.llvm.org/D56141
…On Tue, Dec 15, 2020 at 5:42 AM Hauke Mehrtens ***@***.***> wrote:
It looks like it is working with GCC 10.2:
[ 1.658330] Freeing unused kernel image memory: 2016K
[ 1.662738] Freeing unused kernel image memory: 1248K
[ 1.666034] Run /sbin/init as init process
==1==WARNING: reading executable name failed with errno 2, some stack frames may not be symbolized
==1==WARNING: reading executable name failed with errno 2, some stack frames may not be symbolized
==1==AddressSanitizer: failed to intercept '__isoc99_printf'
'==1==AddressSanitizer: failed to intercept '__isoc99_sprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_snprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_fprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_vprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
'==1==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
'==1==AddressSanitizer: failed to intercept 'xdr_quad_t'
[ 1.787564] random: fast init done
'==1==AddressSanitizer: failed to intercept 'xdr_u_quad_t'
'==1==AddressSanitizer: failed to intercept 'crypt'
'==1==AddressSanitizer: failed to intercept 'crypt_r'
'==1==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==1==Installed the sigaction for signal 11
==1==Installed the sigaction for signal 7
==1==Installed the sigaction for signal 8
==1==T0: stack [0x000000000000,0x000000000000) size 0x0; local=0x7fff6c8cb0ec
==1==AddressSanitizer Init done
[ 1.877074] tsc: Refined TSC clocksource calibration: 1799.999 MHz
[ 1.884175] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x19f228ab7a2, max_idle_ns: 440795289252 ns
[ 1.917634] clocksource: Switched to clocksource tsc
[ 1.932398] init: Console is alive
....
I think this fixed the problem: ***@***.***
<google/llvm-propeller@15b71ea>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1358 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADG4SXFCSZCO2AC3XCGWQDSU5RS5ANCNFSM4U4JL2VA>
.
|
|
@eugenis Do you know if this will also successfully sanitize /init without affecting any features? i.e. does not having /proc/ access initially break anything further down the line? Does ASan strictly need /proc/ access to work without issues, and if so does it automatically start working once /proc/ is available/mounted? |
|
It will disable the fast (frame pointer) unwinder because that can not be
done safely without knowing the stack bounds. ASan gets that info at the
thread or program start and does not try again later. Fast unwind is used
for malloc/free stack traces by default so you'll get empty ones. Not sure
what else will break, maybe symbolization but I think there is some retry
logic there.
Try adding a memory bug and see how it comes up.
…On Wed, Jun 23, 2021 at 2:21 AM manscrober ***@***.***> wrote:
@eugenis <https://github.com/eugenis> Do you know if this will also
successfully sanitize /init without affecting any features? i.e. does not
having /proc/ access initially break anything further down the line? Does
ASan strictly need /proc/ access to work without issues, and if so does it
automatically start working once /proc/ is available/mounted?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1358 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADG4SUIHGVMONJTMZ3DVFDTUGRRVANCNFSM4U4JL2VA>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I want to activate ASAN and also other sanitizers for the complete OpenWrt user space. It is pretty easy to compile the complete user space with ASAN activated, but I have a problem with the init daemon.
The init process is started by the kernel and takes care of mounting /proc /sys and other things. When the process itself is compiled with ASAN, ASAN tries to access /proc before the application is started and mounted it, this fails, the init daemon fails and the kernel panics.
I could try to statically link and not activate ASAN for the init process or try to load different shared libraries which are not instrumented with ASAN.
Is there a better approach? I do not need ASAN support for the init process, if I can use ASAN with the rest it would be fine for me.
Currently it loads multiple shared libraries which I would like to instrument when they are used with other processes.
Is it possible to build some stump for ASAN which just forwards the function calls to the normal glibc and does nothing else?
I am using x86_64 with Linux 5.4, GCC 8.4 (will update to 10.2 today), glibc 2.32 and binutils 2.34.
I am getting this error message:
Hauke
The text was updated successfully, but these errors were encountered: