lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Feb 2022 18:22:22 -0800 From: Kees Cook <keescook@...omium.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Matthew Wilcox <willy@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>, linux-mm@...ck.org, Muhammad Usama Anjum <usama.anjum@...labora.com>, David Laight <David.Laight@...lab.com>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH v3] usercopy: Check valid lifetime via stack depth On Fri, Feb 25, 2022 at 05:46:57PM -0800, Andrew Morton wrote: > On Fri, 25 Feb 2022 17:35:49 -0800 Kees Cook <keescook@...omium.org> wrote: > > > On Fri, Feb 25, 2022 at 04:01:57PM -0800, Andrew Morton wrote: > > > On Fri, 25 Feb 2022 09:33:45 -0800 Kees Cook <keescook@...omium.org> wrote: > > > > > > > Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking > > > > is not available (i.e. everything except x86 with FRAME_POINTER), check > > > > a stack object as being at least "current depth valid", in the sense > > > > that any object within the stack region but not between start-of-stack > > > > and current_stack_pointer should be considered unavailable (i.e. its > > > > lifetime is from a call no longer present on the stack). > > > > > > > > Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures > > > > have actually implemented the common global register alias. > > > > > > > > Additionally report usercopy bounds checking failures with an offset > > > > from current_stack_pointer, which may assist with diagnosing failures. > > > > > > > > The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests > > > > (once slightly adjusted in a separate patch) will pass again with > > > > this fixed. > > > > > > Again, what does this actually do? > > > > [answers] > > > > OK, thanks. I think a new changelog is warranted? Yup, I've cut/pasted most of that into the new changelog: usercopy: Check valid lifetime via stack depth One of the things that CONFIG_HARDENED_USERCOPY sanity-checks is whether an object that is about to be copied to/from userspace is overlapping the stack at all. If it is, it performs a number of inexpensive bounds checks. One of the finer-grained checks is whether an object crosses stack frames within the stack region. Doing this on x86 with CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC was deemed too heavy, and was left out (a while ago), leaving the courser whole-stack check. The LKDTM tests USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM try to exercise these cross-frame cases to validate the defense is working. They have been failing ever since ORC was added (which was expected). While Muhammad was investigating various LKDTM failures[1], he asked me for additional details on them, and I realized that when exact stack frame boundary checking is not available (i.e. everything except x86 with FRAME_POINTER), it could check if a stack object is at least "current depth valid", in the sense that any object within the stack region but not between start-of-stack and current_stack_pointer should be considered unavailable (i.e. its lifetime is from a call no longer present on the stack). Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures have actually implemented the common global register alias. Additionally report usercopy bounds checking failures with an offset from current_stack_pointer, which may assist with diagnosing failures. The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests (once slightly adjusted in a separate patch) pass again with this fixed. [1] https://github.com/kernelci/kernelci-project/issues/84 Cc: Matthew Wilcox (Oracle) <willy@...radead.org> Cc: Josh Poimboeuf <jpoimboe@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org> Cc: linux-mm@...ck.org Reported-by: Muhammad Usama Anjum <usama.anjum@...labora.com> Signed-off-by: Kees Cook <keescook@...omium.org> --- v1: https://lore.kernel.org/lkml/20220216201449.2087956-1-keescook@chromium.org v2: https://lore.kernel.org/lkml/20220224060342.1855457-1-keescook@chromium.org v3: https://lore.kernel.org/lkml/20220225173345.3358109-1-keescook@chromium.org v4: - improve commit log (akpm) > What's your preferred path for upstreaming this change? I figured I would take it via my for-next/hardening tree; I have 2 arch changes ready to go (Acked by maintainers) there too (to add current_stack_pointer). Thanks for the review! -- Kees Cook
Powered by blists - more mailing lists