Messages in this thread | | | Date | Tue, 24 Mar 2020 13:52:32 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] objtool: Documentation: document UACCESS warnings |
| |
On Mon, Mar 23, 2020 at 05:13:20PM -0700, Nick Desaulniers wrote: > Compiling with Clang and CONFIG_KASAN=y was exposing a few warnings: > call to memset() with UACCESS enabled > > Document how to fix these for future travelers. > > Link: https://github.com/ClangBuiltLinux/linux/issues/876 > Suggested-by: Peter Zijlstra <peterz@infradead.org> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> > --- > .../Documentation/stack-validation.txt | 20 +++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/stack-validation.txt > index de094670050b..156fee13ba02 100644 > --- a/tools/objtool/Documentation/stack-validation.txt > +++ b/tools/objtool/Documentation/stack-validation.txt > @@ -289,6 +289,26 @@ they mean, and suggestions for how to fix them. > might be corrupt due to a gcc bug. For more details, see: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > > +9. file.o: warning: objtool: funcA() call to funcB() with UACCESS enabled > + > + This means that an unexpected call to a non-whitelisted function exists > + outside of arch-specific guards. > + X86: SMAP (stac/clac): __uaccess_begin()/__uaccess_end() > + ARM: PAN: uaccess_enable()/uaccess_enable() > + > + These functions should called to denote a minimal critical section around > + access to __user variables. See also: https://lwn.net/Articles/517475/ > + > + The intention of the warning is to prevent calls to funcB() from eventually > + calling schedule(), potentially leaking the AC flags state, and not > + restoring them correctly. > + > + To fix, either: > + 1) add the correct guards before and after calls to low level functions like > + __get_user_size()/__put_user_size(). > + 2) add funcB to uaccess_safe_builtin whitelist in tools/objtool/check.c, if > + funcB obviously does not call schedule().
There's sadly nothing obvious about 2); __fentry__ is enough to end up in schedule() through preempt_enable().
So any function that has function tracing on (mostly everything) is already disqualified.
| |