From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 991DBC433F5 for ; Wed, 22 Sep 2021 15:30:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7981161168 for ; Wed, 22 Sep 2021 15:30:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236448AbhIVPcP (ORCPT ); Wed, 22 Sep 2021 11:32:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236443AbhIVPcN (ORCPT ); Wed, 22 Sep 2021 11:32:13 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C49CBC061756 for ; Wed, 22 Sep 2021 08:30:43 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id q23so3003195pfs.9 for ; Wed, 22 Sep 2021 08:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uG8kbMDq3wWFr/zeapZnykzvzoN7SSQeT88JzB5wbWE=; b=PmZIAxL0qI0ZUjgkEKbm/alrr9/0KQGVptK74f5bXbBYVa7zokeLn8N3pGkUV55CfI DAGkFnpsgbZc2MGiCPciF6VSHahGpJCkzssEe0ITNqYGY5viUeYZaDEcpNNsKG7uJoF0 ZvfoUXuemAsGMxl15kJkc+y3OXSGOclJt5wXc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uG8kbMDq3wWFr/zeapZnykzvzoN7SSQeT88JzB5wbWE=; b=IWJtNAq6LtGlII4+PU79qssmt4MAw0ba9lVyvUqYg1M9wGuvRQfrzCSyOcs/piw+UE bdQLzV3Az5AJBVpjqTkgSrnzBKJLAiGB1vpR+/VkPnFmmoywmR5NkbaRAhJuIEkq5Ewm 8qSt+3glwGrJo0ijRdeg8uuAZ+8j1zRhTrOgSqjyVnSkyqMOndMkL6sJ+5W4hdeo49K3 z8elOpJIRBMAWMm6QeO3oqwxvqa1hcy2Uw1Ob98roRG6NduweKRuNcjFRkT7NRTFR74Y blphgsV3voQE0NdQSSHyWguRT/j2xbbd1ASg2OVL5j3A8thvxj9vG+evbiRZpdeDpuMp 7AQw== X-Gm-Message-State: AOAM533MknsZofbKCRLkPP6R/ktK83BQI+t4rAYUagb6hdr12buShlDk tevdPShBuVR/KBtDc0H09EBAcw== X-Google-Smtp-Source: ABdhPJz7U8r0IYlJkaTUi1d6EowadRFph6RW0II+c9Yh+WaHWwqTzkXXlAWA8N8ZPDEqXdM+hLiuNA== X-Received: by 2002:a63:480b:: with SMTP id v11mr183763pga.413.1632324643268; Wed, 22 Sep 2021 08:30:43 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id k29sm2941045pfp.200.2021.09.22.08.30.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 08:30:41 -0700 (PDT) Date: Wed, 22 Sep 2021 08:30:40 -0700 From: Kees Cook To: "Eric W. Biederman" , Peter Collingbourne Cc: Jann Horn , Catalin Marinas , Will Deacon , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Thomas Gleixner , Andy Lutomirski , Andrew Morton , Masahiro Yamada , Sami Tolvanen , YiFei Zhu , Colin Ian King , Mark Rutland , Frederic Weisbecker , Viresh Kumar , Andrey Konovalov , Gabriel Krisman Bertazi , Balbir Singh , Chris Hyser , Daniel Vetter , Chris Wilson , Arnd Bergmann , Dmitry Vyukov , Christian Brauner , Alexey Gladkov , Ran Xiaokai , David Hildenbrand , Xiaofeng Cao , Cyrill Gorcunov , Thomas Cedeno , Marco Elver , Alexander Potapenko , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Evgenii Stepanov Subject: Re: [PATCH] kernel: introduce prctl(PR_LOG_UACCESS) Message-ID: <202109220755.B0CFED9F5@keescook> References: <20210922061809.736124-1-pcc@google.com> <87k0j8zo35.fsf@disp2133> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0j8zo35.fsf@disp2133> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 22, 2021 at 09:23:10AM -0500, Eric W. Biederman wrote: > Peter Collingbourne writes: > > > This patch introduces a kernel feature known as uaccess logging. > > With uaccess logging, the userspace program passes the address and size > > of a so-called uaccess buffer to the kernel via a prctl(). The prctl() > > is a request for the kernel to log any uaccesses made during the next > > syscall to the uaccess buffer. When the next syscall returns, the address > > one past the end of the logged uaccess buffer entries is written to the > > location specified by the third argument to the prctl(). In this way, > > the userspace program may enumerate the uaccesses logged to the access > > buffer to determine which accesses occurred. > > [...] > > 3) Kernel fuzzing. We may use the list of reported kernel accesses to > > guide a kernel fuzzing tool such as syzkaller (so that it knows which > > parts of user memory to fuzz), as an alternative to providing the tool > > with a list of syscalls and their uaccesses (which again thanks to > > (2) may not be accurate). > > How is logging the kernel's activity like this not a significant > information leak? How is this safe for unprivileged users? This does result in userspace being able to "watch" the kernel progress through a syscall. I'd say it's less dangerous than userfaultfd, but still worrisome. (And userfaultfd is normally disabled[1] for unprivileged users trying to interpose the kernel accessing user memory.) Regardless, this is a pretty useful tool for this kind of fuzzing. Perhaps the timing exposure could be mitigated by having the kernel collect the record in a separate kernel-allocated buffer and flush the results to userspace at syscall exit? (This would solve the copy_to_user() recursion issue too.) I'm pondering what else might be getting exposed by creating this level of probing... kernel addresses would already be getting rejected, so they wouldn't show up in the buffer. Hmm. Jann, any thoughts here? Some other thoughts: Instead of reimplementing copy_*_user() with a new wrapper that bypasses some checks and adds others and has to stay in sync, etc, how about just adding a "recursion" flag? Something like: copy_from_user(...) instrument_copy_from_user(...) uaccess_buffer_log_read(...) if (current->uaccess_buffer.writing) return; uaccess_buffer_log(...) current->uaccess_buffer.writing = true; copy_to_user(...) current->uaccess_buffer.writing = false; How about using this via seccomp instead of a per-syscall prctl? This would mean you would have very specific control over which syscalls should get the uaccess tracing, and wouldn't need to deal with the signal mask (I think). I would imagine something similar to SECCOMP_FILTER_FLAG_LOG, maybe SECCOMP_FILTER_FLAG_UACCESS_TRACE, and add a new top-level seccomp command, (like SECCOMP_GET_NOTIF_SIZES) maybe named SECCOMP_SET_UACCESS_TRACE_BUFFER. This would likely only make sense for SECCOMP_RET_TRACE or _TRAP if the program wants to collect the results after every syscall. And maybe this won't make any sense across exec (losing the mm that was used during SECCOMP_SET_UACCESS_TRACE_BUFFER). Hmmm. -Kees [1] https://git.kernel.org/linus/d0d4730ac2e404a5b0da9a87ef38c73e51cb1664 -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D40E2C433EF for ; Wed, 22 Sep 2021 15:33:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A337861168 for ; Wed, 22 Sep 2021 15:33:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A337861168 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KYuAy6EIE5C7tr6VsLhyquk6WxxnUn4NWeZwDNPAcMk=; b=W3/M/luRwtzhqi kUkliicXb9jAaWluCi3Os/Ao68qk3qe+u/v6rX98NbtI2T4+q3P38YWb1O5ylxRlmSd9SWFKwe3n0 nJfywnFrKpbZQwaX+acdi8Qhr2dVe7BTVghOBWC/RixAkXaf7SQF9cvc+0b1DFo2yLPNj96lDUR4X SSJdrDDuewBVm0dbrJ6eqEfDqokr28ju8cRawI7ZZN88njyJjt0HLIru0A3WDYUkBvTLIcvtEETWY uiF3qOy/tQrXXjiIzMUyE4ge5X+O9QrkHM8c/tz3WzVI97UcSKBKe1iRtgWn/7zuw9C05N80ZOSkF fZRdg3UFDNB9bTXAh/wg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mT4Cu-008wbd-T3; Wed, 22 Sep 2021 15:30:49 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mT4Cr-008waY-6T for linux-arm-kernel@lists.infradead.org; Wed, 22 Sep 2021 15:30:46 +0000 Received: by mail-pf1-x42f.google.com with SMTP id s16so3095048pfk.0 for ; Wed, 22 Sep 2021 08:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uG8kbMDq3wWFr/zeapZnykzvzoN7SSQeT88JzB5wbWE=; b=PmZIAxL0qI0ZUjgkEKbm/alrr9/0KQGVptK74f5bXbBYVa7zokeLn8N3pGkUV55CfI DAGkFnpsgbZc2MGiCPciF6VSHahGpJCkzssEe0ITNqYGY5viUeYZaDEcpNNsKG7uJoF0 ZvfoUXuemAsGMxl15kJkc+y3OXSGOclJt5wXc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uG8kbMDq3wWFr/zeapZnykzvzoN7SSQeT88JzB5wbWE=; b=8JNKbkKAH3mdjQPaZzH8nBNyrDxiwQMYlwa1dLdwZC9cqLCRqEFNKND+rSp7hT7FDC VZ3n1ahBZTiYzH3htimUjhqlyXb1uW8nOXVuqbDf4Nn4ldD0lL2rGyhOZCOnQO+9rVo/ 7lqgUyouk8TG3rcmOGuH5V3phTELou3L2szNR/yog1ERER7zL86B4h1C8IurqDBiANiE rOXOlZiT799ora1upegFeejfUcRvW5JpnpXXFfm4MzznjTNwCem+UZ6iLLq792j7UdnD XfuAn+kLF6Khz6FfeSxgp87S0Aretpx2QbT40MMs1533spyb1XbQyNUuswIu6nzSmRc7 /0cw== X-Gm-Message-State: AOAM530VmKxbvJmlorfxz5IKMC7KVj2Cl+KrA6XqL7lSpWGxUmheO3mk zV3AUv6YccUycHQagtu/K/svrQ== X-Google-Smtp-Source: ABdhPJz7U8r0IYlJkaTUi1d6EowadRFph6RW0II+c9Yh+WaHWwqTzkXXlAWA8N8ZPDEqXdM+hLiuNA== X-Received: by 2002:a63:480b:: with SMTP id v11mr183763pga.413.1632324643268; Wed, 22 Sep 2021 08:30:43 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id k29sm2941045pfp.200.2021.09.22.08.30.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 08:30:41 -0700 (PDT) Date: Wed, 22 Sep 2021 08:30:40 -0700 From: Kees Cook To: "Eric W. Biederman" , Peter Collingbourne Cc: Jann Horn , Catalin Marinas , Will Deacon , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Thomas Gleixner , Andy Lutomirski , Andrew Morton , Masahiro Yamada , Sami Tolvanen , YiFei Zhu , Colin Ian King , Mark Rutland , Frederic Weisbecker , Viresh Kumar , Andrey Konovalov , Gabriel Krisman Bertazi , Balbir Singh , Chris Hyser , Daniel Vetter , Chris Wilson , Arnd Bergmann , Dmitry Vyukov , Christian Brauner , Alexey Gladkov , Ran Xiaokai , David Hildenbrand , Xiaofeng Cao , Cyrill Gorcunov , Thomas Cedeno , Marco Elver , Alexander Potapenko , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Evgenii Stepanov Subject: Re: [PATCH] kernel: introduce prctl(PR_LOG_UACCESS) Message-ID: <202109220755.B0CFED9F5@keescook> References: <20210922061809.736124-1-pcc@google.com> <87k0j8zo35.fsf@disp2133> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87k0j8zo35.fsf@disp2133> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210922_083045_306274_0507076D X-CRM114-Status: GOOD ( 31.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 22, 2021 at 09:23:10AM -0500, Eric W. Biederman wrote: > Peter Collingbourne writes: > > > This patch introduces a kernel feature known as uaccess logging. > > With uaccess logging, the userspace program passes the address and size > > of a so-called uaccess buffer to the kernel via a prctl(). The prctl() > > is a request for the kernel to log any uaccesses made during the next > > syscall to the uaccess buffer. When the next syscall returns, the address > > one past the end of the logged uaccess buffer entries is written to the > > location specified by the third argument to the prctl(). In this way, > > the userspace program may enumerate the uaccesses logged to the access > > buffer to determine which accesses occurred. > > [...] > > 3) Kernel fuzzing. We may use the list of reported kernel accesses to > > guide a kernel fuzzing tool such as syzkaller (so that it knows which > > parts of user memory to fuzz), as an alternative to providing the tool > > with a list of syscalls and their uaccesses (which again thanks to > > (2) may not be accurate). > > How is logging the kernel's activity like this not a significant > information leak? How is this safe for unprivileged users? This does result in userspace being able to "watch" the kernel progress through a syscall. I'd say it's less dangerous than userfaultfd, but still worrisome. (And userfaultfd is normally disabled[1] for unprivileged users trying to interpose the kernel accessing user memory.) Regardless, this is a pretty useful tool for this kind of fuzzing. Perhaps the timing exposure could be mitigated by having the kernel collect the record in a separate kernel-allocated buffer and flush the results to userspace at syscall exit? (This would solve the copy_to_user() recursion issue too.) I'm pondering what else might be getting exposed by creating this level of probing... kernel addresses would already be getting rejected, so they wouldn't show up in the buffer. Hmm. Jann, any thoughts here? Some other thoughts: Instead of reimplementing copy_*_user() with a new wrapper that bypasses some checks and adds others and has to stay in sync, etc, how about just adding a "recursion" flag? Something like: copy_from_user(...) instrument_copy_from_user(...) uaccess_buffer_log_read(...) if (current->uaccess_buffer.writing) return; uaccess_buffer_log(...) current->uaccess_buffer.writing = true; copy_to_user(...) current->uaccess_buffer.writing = false; How about using this via seccomp instead of a per-syscall prctl? This would mean you would have very specific control over which syscalls should get the uaccess tracing, and wouldn't need to deal with the signal mask (I think). I would imagine something similar to SECCOMP_FILTER_FLAG_LOG, maybe SECCOMP_FILTER_FLAG_UACCESS_TRACE, and add a new top-level seccomp command, (like SECCOMP_GET_NOTIF_SIZES) maybe named SECCOMP_SET_UACCESS_TRACE_BUFFER. This would likely only make sense for SECCOMP_RET_TRACE or _TRAP if the program wants to collect the results after every syscall. And maybe this won't make any sense across exec (losing the mm that was used during SECCOMP_SET_UACCESS_TRACE_BUFFER). Hmmm. -Kees [1] https://git.kernel.org/linus/d0d4730ac2e404a5b0da9a87ef38c73e51cb1664 -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel