You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is regarding ubsan support for kpatch. ubuntu recently queried regarding this option on s390.
I quickly tested it on x86 and it seems to fail on x86 in a similar way.
I did perform initial preliminary analysis. These are my current findings.
Debug data:
2a. buggy program:
#include <stdio.h>
int main(int argc, char **argv) {
int arr[100];
arr[101] = 1;
printf("arr[101] = %d", arr[101]);
return 0;
}
String dump of section '.data..Lubsan_type0':
[ 4] 'int [100]'
2g. readelf -p .data..Lubsan_type1 sample.o :
[ 4] 'int'
Solution 1:
Disable ubsan config for patched functions. kernel build can still run with ubsan enabled.
Code generated by patched functions wouldnt contain for eg. __ubsan_handle_out_of_bounds
diff --git a/kpatch-build/kpatch-build b/kpatch-build/kpatch-build
index 45e8b14..28daf54 100755
--- a/kpatch-build/kpatch-build
+++ b/kpatch-build/kpatch-build
@@ -989,6 +989,8 @@ if [[ -z "$OOT_MODULE" && ! "$CONFIGFILE" -ef "$KERNEL_SRCDIR"/.config ]] ; then
cp -f "$CONFIGFILE" "$KERNEL_SRCDIR/.config" || die
fi
+# Dont compile patched functions with ubsan
+"$KERNEL_SRCDIR"/scripts/config --set-val CONFIG_UBSAN n || die "couldnt disable UBSAN"
# kernel option checking
trace_off "reading .config"
Question/Solution 2:
As per my understanding, kpatch can deal with:
modified and new functions,
addition of new data.
Can it also support modification to other .data.* ?
Considering these References:
303928f ("create-diff-object: ensure no data sections are included")
2982962 ("support for__key and __warned special static local vars")
patch-author-guide.md: Data structure changes
kpatch patches functions, not data. If the original patch involves a change to a data structure, the patch will require some rework, as changes to data structures are not allowed by default.
In the below patch, I avoided correlating the .data.Lubsan_* and this means inclusion of the new .data.Lubsan* sections. Considering the fact that .data.Lubsan* contains linenumber, filename and datatype info, Is it safe to include the new .data.Lubsan* ?
I just ran a simple test on this and new data are reflected, Also, when the array is out of bounds in the patched functions
a warning is thrown. unloading points to the old data.
Hi all,
This is regarding ubsan support for kpatch. ubuntu recently queried regarding this option on s390.
I quickly tested it on x86 and it seems to fail on x86 in a similar way.
I did perform initial preliminary analysis. These are my current findings.
Debug data:
2a. buggy program:
2b. Disassembly and relocs:
2c. .data.*Lubsan represents struct out_of_bounds_data, which is declared in linux/lib/ubsan.h
2d. Disassembly of section .data..Lubsan_data1:
2e. readelf -p .rodata sample.o
2f. readelf -p .data..Lubsan_type0 sample.o
2g. readelf -p .data..Lubsan_type1 sample.o :
Solution 1:
Disable ubsan config for patched functions. kernel build can still run with ubsan enabled.
Code generated by patched functions wouldnt contain for eg. __ubsan_handle_out_of_bounds
Question/Solution 2:
As per my understanding, kpatch can deal with:
kpatch patches functions, not data. If the original patch involves a change to a data structure, the patch will require some rework, as changes to data structures are not allowed by default.
In the below patch, I avoided correlating the .data.Lubsan_* and this means inclusion of the new .data.Lubsan* sections. Considering the fact that .data.Lubsan* contains linenumber, filename and datatype info, Is it safe to include the new .data.Lubsan* ?
I just ran a simple test on this and new data are reflected, Also, when the array is out of bounds in the patched functions
a warning is thrown. unloading points to the old data.
Request for your suggestions and feedback.
Thank you,
Sumanth
The text was updated successfully, but these errors were encountered: