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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D987FC433EF for ; Sun, 14 Nov 2021 02:54:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A9B960FE8 for ; Sun, 14 Nov 2021 02:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230441AbhKNC5R (ORCPT ); Sat, 13 Nov 2021 21:57:17 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:21222 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230299AbhKNC5R (ORCPT ); Sat, 13 Nov 2021 21:57:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636858463; 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=Z11TsBOkpLgn28Euq8Rc6AR7QYaBCEGbaI3sb04YAYM=; b=UcLrfjIyOc3oyC9VQg0bxYaAAiKol3bzM8ppm/GX6CILjS+lt0GY3lkYmBVuWAAfuNjI04 FocNAwiBmSfwZYjs4pTrXkrXME39tFGVzfNGICo2MaLVPeQJ4M2LzDXbeu7AAMVHvzUIwz NeBDNnbvkhuI7qa2aCpCJZwqf7dulQk= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-447-oLzzmTfxOlmB9ogtA0XSHQ-1; Sat, 13 Nov 2021 21:54:22 -0500 X-MC-Unique: oLzzmTfxOlmB9ogtA0XSHQ-1 Received: by mail-qv1-f71.google.com with SMTP id g12-20020a0562141ccc00b003c0322ea7b6so6613489qvd.19 for ; Sat, 13 Nov 2021 18:54:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Z11TsBOkpLgn28Euq8Rc6AR7QYaBCEGbaI3sb04YAYM=; b=pMbx5SK8sKFbntj9Uqd3raU1AqrM57ukIqwTXyLK0ECMQD/lWS7VIZKK/+ruOuzcsA JJ0sAAtxpqUHeZ0yeeN4kvCcp3+2RxtUoTx1x8pUUNIP+ySvEMmWQM+IUlAKdYMMngnz W5nwjwCO8G9rARoLPvsOUOQwZaNha6GlvjG+wzFNWHHmCMJRQ8Y3OIg5iyhBToZHoCEy NbE0xjP3+klK6PRWffPhDSpMAacE7QdIkGSeKJZvaGkcG56IaxR1TXzrJvnURE/+ltnF 9Ox//bKa6me5ui+4UZvXZGciXJwnDcknPHuzgDE+z7yg3RTGx1cClVSgnqWAUwYubtVn drpA== X-Gm-Message-State: AOAM532pk22r/6ulEN0P5tjzeJgP0F/dFYUE7CCLDhfaUU8De7sUgrma d+hwswti3EHAOmDG5JUvnKvUsPtdP44F160XsVB8XsRCcGqdQcqUnHKqCxRo6oo9lJ6KVITXkA2 x97LLjSVP+bpYUkDdzs1wDQzjZ7luaA== X-Received: by 2002:ac8:44bc:: with SMTP id a28mr30128720qto.149.1636858461507; Sat, 13 Nov 2021 18:54:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZFc36V11Rn3FUZ5Bi3ZLZbilwg8/G12N8PnJgSB4XFl+HBMcxS+MzEx2Uti/2FcXcBRkddQ== X-Received: by 2002:ac8:44bc:: with SMTP id a28mr30128698qto.149.1636858461266; Sat, 13 Nov 2021 18:54:21 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id v12sm366123qtx.80.2021.11.13.18.54.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 18:54:20 -0800 (PST) Message-ID: <4d1595896d84e1d9fe2cf80676e241630fb497fb.camel@redhat.com> Subject: Re: [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries From: David Malcolm To: Peter Zijlstra Cc: gcc-patches@gcc.gnu.org, linux-toolchains@vger.kernel.org Date: Sat, 13 Nov 2021 21:54:19 -0500 In-Reply-To: <20211113232047.GM174703@worktop.programming.kicks-ass.net> References: <20211113203732.2098220-1-dmalcolm@redhat.com> <20211113232047.GM174703@worktop.programming.kicks-ass.net> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Sun, 2021-11-14 at 00:20 +0100, Peter Zijlstra wrote: > On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote: > > > This approach is much less expressive that the custom addres space > > approach; it would only cover the trust boundary aspect; it > > wouldn't > > cover any differences between generic pointers and __user, vs > > __iomem, > > __percpu, and __rcu which I admit I only dimly understand. > > __iomem would point at device memory, which can have curious side > effects or is yet another trust boundary, depending on device and > usage. > > __percpu is an address space that denotes a per-cpu variable's > relative > offset, it needs be combined with a per-cpu offset to get a 'real' > pointer, on x86_64 %gs segment offset is used for this purpose, other > architectures are less fortunate. The whole per_cpu()/this_cpu_*() > family of APIs accepts such pointers. > > __rcu is the regular kernel address space, but denotes that the > object > pointed to has RCU lifetime management. The attribute is laundered > through rcu_dereference() to remove the __rcu qualifier. Thanks; this is very helpful. > > > Possibly silly question: is it always a bug for the value of a > > kernel > > pointer to leak into user space?  i.e. should I be complaining > > about an > > infoleak if the value of a trusted_ptr itself is written to > > *untrusted_ptr?  e.g. > > Yes, always. Leaking kernel pointers is unconditionally bad. Thanks. FWIW I've thrown together a new warning in -fanalyzer for this, e.g. given: /* Some kernel space thing, where the address is presumably secret */ struct foo_t { } foo; /* Response struct for some ioctl/syscall */ struct s1 { void *ptr; }; void test_1 (void __user *p) { struct s1 s = {0}; s.ptr = &foo; copy_to_user (p, &s, sizeof (s)); } ...my code emits... infoleak-ptr-1.c: In function ‘test_1’: infoleak-ptr-1.c:17:3: warning: potential exposure of sensitive information by copying pointer ‘&foo’ across trust boundary [-Wanalyzer-exposure-of-pointer] 17 | copy_to_user (p, &s, sizeof (s)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ but it strikes me that there could be other sensitive information beyond just the values of kernel-space pointers that must not cross a trust boundary. GCC's -fanalyzer currently has a state machine for tracking "sensitive" values, but it's currently just a proof-of-concept that merely treats the result of the user-space API "getpass" as sensitive (with a demo of detecting passwords being exposed via logfiles). Any ideas on other values in the kernel that it would be useful to treat as "sensitive"? (maybe crypto private keys??? other internal state???) I can do it by types, by results of functions, etc. That said, I'm not modeling the kernel's own access model (root vs regular user etc) in the analyzer, so maybe extending things beyond kernel space addresses is misguided? Hope this is constructive Dave