x86_64, vsyscall: fix the oops crash with __pa_vsymbol()
PATCH 1/1 x86_64, vsyscall: fix the oops crash with __pa_vsymbol()
Appended patch fixes an oops while changing the vsyscall sysctl. I am sure no one tested this code before integrating into mainline :(
BTW, using ioremap() in vsyscall_sysctl_change() to get the virtual address of a kernel symbol sounds like an over kill.. I wonder if we can define a simple __va_vsymbol() which will return directly the kernel direct mapping. comments in the code which says gcc has trouble with __va(__pa()) sounds bogus to me. __pa() on a vsyscall address will not work anyhow :(
And also, the whole nop out syscall in vsyscall page infrastructure (vsyscall_sysctl_change()) is added to make some attacks difficult, and yet I don't see this nop out being done by default. This area requires more cleanups?
thanks,
suresh
---
Fix an oops with __pa_vsymbol(). VSYSCALL_FIRST_PAGE is a fixmap index. We want the starting virtual address of the vsyscall page and not the index.
---
arch/x86_64/kernel/vsyscall.c +1 -1
@@ -50,7 +50,7 @@ ({unsigned long v; \extern char __vsyscall_0; \ asm("" :"=r" (v) :"0" (x)); \ - ((v -VSYSCALL_FIRST_PAGE ) +__pa_symbol (&__vsyscall_0)); }) + ((v -VSYSCALL_START ) +__pa_symbol (&__vsyscall_0)); })/* * vsyscall_gtod_data contains data that is :
Quoted 2 lines · Suresh B
Appended patch fixes an oops while changing the vsyscall sysctl. I am sure no one tested this code before integrating into mainline :(
The original code worked, but got broken by 0dbf7028c0c1f266c9631139450a1502d3cd457e
Quoted 3 lines
BTW, using
ioremap()invsyscall_sysctl_change()to get the virtual address of a kernel symbol sounds like an over kill.
Another point was to get a writable mapping. At some point we had write protected kernels, although that was later then removed again.
Quoted 4 lines
And also, the whole nop out syscall in vsyscall page infrastructure (
vsyscall_sysctl_change()) is added to make some attacks difficult, and yet I don't see this nop out being done by default. This area requires more cleanups?
It used to be done, but it is difficult with the changing vreads in timesources and was probably disabled then. Yes you're right right now it looks dubious.
It needs to be updated when the timesource is updated.
-Andi
Quoted 6 lines · Andi Kleen
Quoted 2 lines · Suresh B
Appended patch fixes an oops while changing the vsyscall sysctl. I am sure no one tested this code before integrating into mainline :(
The original code worked, but got broken by
0dbf7028c0c1f266c9631139450a1502d3cd457eQuoted 1 line
Yep. My mistake. I did not test this aspect of the patch. System booted fine with all the applications running so I assumed things are fine.
Thanks Suresh. This patch looks good.
Thanks
Vivek