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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 73B56C433F5 for ; Wed, 22 Sep 2021 17:48:58 +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 356C561156 for ; Wed, 22 Sep 2021 17:48:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 356C561156 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HKlOlsA4p9gRl+ftu+PBaq6GZ4BzH12uwwEbJmzDzLQ=; b=nzni4x8vn3MRon1TGyguUV8M6R rodkjrNF7cp+lnkhUuKR5vljem1E5kbAdn8FH9/RBVEnx55KWo7NLJ1cvbZuMPGLJZuo4iFzzx/OL WXLD82pTwmlNyG1A8rQl0f7IYrrQxpwuPld4dGjpu+6pAnloUdvnl0rvAPvjh738as7ddiiiTT8hJ HYagQyv4ZTmAyxwlQ/K/nlOoWmV7uztriLzde9EYPFSsBNZ/QbJpGv4VtAguVk7EDTbPHuyVzAEzP FMyFlGANzXCN4TniuIK3Thlr3IrNxSgBmfWk6MERRl3R+N+go+jlqo5Z1TFxBkk/6qmSkL6eDLD8n Dg+KfIIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mT6Kh-009Nn4-MO; Wed, 22 Sep 2021 17:46:59 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mT6Kd-009NmI-RH for linux-arm-kernel@lists.infradead.org; Wed, 22 Sep 2021 17:46:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632332812; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yRAZvQi8QIkG/wXBuwsGoebLhQmRDzUFn2QwIAEv05c=; b=P5y+anksRK78l/tnr0c40fWZyu3lkGVtgioY/7G36wdga/nc85XEjKG+I4iUdE+YgKIkHO EvaRlBNB4q4t6y0Yd6vbeGB+qARLYICh6RDzCqoWCnVcxy7DjqaqUSO5SUKAAdii01R79/ dTY7ZOINj6v1RQjM78OomuRrvjyLZwU= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-448-KEoWx70ENq-FsAeYoV49iw-1; Wed, 22 Sep 2021 13:46:51 -0400 X-MC-Unique: KEoWx70ENq-FsAeYoV49iw-1 Received: by mail-wr1-f71.google.com with SMTP id r5-20020adfb1c5000000b0015cddb7216fso2880115wra.3 for ; Wed, 22 Sep 2021 10:46:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yRAZvQi8QIkG/wXBuwsGoebLhQmRDzUFn2QwIAEv05c=; b=ZxQOZNHWLltxE52m84U8Z6YEgerbFSgz/FJtNzDmoe+epM0tQCsuBlaXH8thEkDGNj IKEHPFzJ2SGgz62kCpp0gQBYT6SeFoifDv5D1R2ou7PVFwobmnXWhYHlDCNzLXOk308b JSsT1KiQIwVE2gpZavSUVi+HLf7PmSBU3AtWMK2nFfqrKH526AZH7kQm86rMtaWvLptv u34BqwPo4QEpzCJkOMFwP+MdUYrV+feiHjmgL9hJ/eM9Pk0Aohx8YH6zfoUNbR8zCizr OxBVFiimSNt1u83MXJTE1Z25i7KnhQEHSJ4xz4gatYvdFtz4kfs33VqbmxiwtW5ahTh0 E1JA== X-Gm-Message-State: AOAM53095kSgxVLc8AVanaT8fC7JOljxFr8hroezBYn8blod0aqGmnyU yr8+34stgunC+igaeO7GTBBRPhMJKo30FUAb0EkLfRIsRkO5MN5Lzb1LoeWf/UpNxs8Ek57DbQV Qu8CUqNVRmPXx3d8y2EKzF9U3WQlN/JZLXlw= X-Received: by 2002:a1c:a505:: with SMTP id o5mr353245wme.32.1632332810406; Wed, 22 Sep 2021 10:46:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRUR+LCJzoCbByZikpE+DxWdrmv2gBJFkOC+eNKZ2z9oQEsfmDCPQOFXlcLMOuckg32hVAdA== X-Received: by 2002:a1c:a505:: with SMTP id o5mr353211wme.32.1632332810108; Wed, 22 Sep 2021 10:46:50 -0700 (PDT) Received: from [192.168.3.132] (p5b0c64dd.dip0.t-ipconnect.de. [91.12.100.221]) by smtp.gmail.com with ESMTPSA id s13sm6872088wmc.47.2021.09.22.10.46.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Sep 2021 10:46:49 -0700 (PDT) Subject: Re: [PATCH] kernel: introduce prctl(PR_LOG_UACCESS) To: Peter Collingbourne , 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 , Kees Cook , 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 , "Eric W. Biederman" , Alexey Gladkov , Ran Xiaokai , Xiaofeng Cao , Cyrill Gorcunov , Thomas Cedeno , Marco Elver , Alexander Potapenko Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Evgenii Stepanov References: <20210922061809.736124-1-pcc@google.com> From: David Hildenbrand Organization: Red Hat Message-ID: <29f1822d-e4cd-eedb-bea8-619db1d56335@redhat.com> Date: Wed, 22 Sep 2021 19:46:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210922061809.736124-1-pcc@google.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210922_104656_020901_A6D8D7CD X-CRM114-Status: GOOD ( 37.80 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 22.09.21 08:18, Peter Collingbourne wrote: > 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. > > Uaccess logging has several use cases focused around bug detection > tools: > > 1) Userspace memory safety tools such as ASan, MSan, HWASan and tools > making use of the ARM Memory Tagging Extension (MTE) need to monitor > all memory accesses in a program so that they can detect memory > errors. For accesses made purely in userspace, this is achieved > via compiler instrumentation, or for MTE, via direct hardware > support. However, accesses made by the kernel on behalf of the > user program via syscalls (i.e. uaccesses) are invisible to these > tools. With MTE there is some level of error detection possible in > the kernel (in synchronous mode, bad accesses generally result in > returning -EFAULT from the syscall), but by the time we get back to > userspace we've lost the information about the address and size of the > failed access, which makes it harder to produce a useful error report. > > With the current versions of the sanitizers, we address this by > interposing the libc syscall stubs with a wrapper that checks the > memory based on what we believe the uaccesses will be. However, this > creates a maintenance burden: each syscall must be annotated with > its uaccesses in order to be recognized by the sanitizer, and these > annotations must be continuously updated as the kernel changes. This > is especially burdensome for syscalls such as ioctl(2) which have a > large surface area of possible uaccesses. > > 2) Verifying the validity of kernel accesses. This can be achieved in > conjunction with the userspace memory safety tools mentioned in (1). > Even a sanitizer whose syscall wrappers have complete knowledge of > the kernel's intended API may vary from the kernel's actual uaccesses > due to kernel bugs. A sanitizer with knowledge of the kernel's actual > uaccesses may produce more accurate error reports that reveal such > bugs. > > An example of such a bug, which was found by an earlier version of this > patch together with a prototype client of the API in HWASan, was fixed > by commit d0efb16294d1 ("net: don't unconditionally copy_from_user > a struct ifreq for socket ioctls"). Although this bug turned out to > relatively harmless, it was a bug nonetheless and it's always possible > that more serious bugs of this sort may be introduced in the future. > > 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). > > All signals except SIGKILL and SIGSTOP are masked for the interval > between the prctl() and the next syscall in order to prevent handlers > for intervening asynchronous signals from issuing syscalls that may > cause uaccesses from the wrong syscall to be logged. Stupid question: can this be exploited from user space to effectively disable SIGKILL for a long time ... and do we care? Like, the application allocates a bunch of memory, issues the prctl() and spins in user space. What would happen if the OOM killer selects this task as a target and does a do_send_sig_info(SIGKILL, SEND_SIG_PRIV, ...) ? -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel