Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1132476pxb; Fri, 6 Nov 2020 01:38:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTym/i0Thrwkw3NCPHvOqqUsVCHPISxRnOssqJ/HPIscmBM8zgAmc0qgCLBGvUiQOYBxgg X-Received: by 2002:a17:906:3899:: with SMTP id q25mr1254575ejd.0.1604655528726; Fri, 06 Nov 2020 01:38:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604655528; cv=none; d=google.com; s=arc-20160816; b=s+brYKPyRoaL1oB+DRXZ5+HQq6jVtKDL5S1U3tzwwMF+ss6oqXRhXRYV2YSak9/nTz KA2dZeFF8y1KObo0VwMKl/9E7PrINdzxWOLZ+7zQ1GYwmpDqlSYZWB3TXFcbAousaGmG z86+u6AeO5nl6CUyokvb4kMg8u/65+xqx+ZmFcD8Af5Cp8dT0KhtON+IUUKbwwgCmwZv Ae4y97yV3+26OZ/mSm6yHNnZpGA1BCVLvISznCwkJRzY1BBx7InAFsgwNPKi8smA6C6S HDdJPWiBBNMsKuJ+CE8F/nw/hLlQGgm8cOj0oW6kedlspn3LbOlRWsIemOtNHbKAg2UY mOVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Xbe1zafvLzFk0NBuZKfqZ6Cyl3GP1S5ka0zb2rUwC3Y=; b=oNoHDQsEgrX5LnTxJAYMgOyhpOjpBqYJn8WqA9GGfzO1ASmATme1Pr20uiiDdqzehN DvPhN0dRDOsg9ZY1QPdA6KTlXGQQpzCV1JDC7qmy9j+EmQ+pjJrfEc3RV6SzBp3CqoKe 4Ujf2L85zXCmkx4gifoeA29ttyWpyFbaF7IBj989iNbwQc3VwztelSX+aM1UMAaNFBbE dQYBPvwTsVd5Ht1z+5aiFpiPE4UwGQiATZe2LEypBycOAnjC/REiLNbs/J7VL08ne54M 2frmDHN1b4e1WFJx76bTmnKcwy7REYYBa4YMTPze5TwItjXOxeWLETdaJNzI09ksRscz DYlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aCr5QBrq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx16si430217ejb.379.2020.11.06.01.38.25; Fri, 06 Nov 2020 01:38:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aCr5QBrq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726139AbgKFJfF (ORCPT + 99 others); Fri, 6 Nov 2020 04:35:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbgKFJfE (ORCPT ); Fri, 6 Nov 2020 04:35:04 -0500 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47ED1C0613CF for ; Fri, 6 Nov 2020 01:35:04 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id d142so696369wmd.4 for ; Fri, 06 Nov 2020 01:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Xbe1zafvLzFk0NBuZKfqZ6Cyl3GP1S5ka0zb2rUwC3Y=; b=aCr5QBrqgXrzRg0NR6myvS6xEIITsQ2Bccqq53y4TRpcpC39vVuVatUdShlYuUwtjz 5Dbe7SGEKcnUlpSR9ydb3ABkuToji9XJqkUBWgJISIaFSb2kK8zYVmJYqURepQefiObs jhkI1moTACYZ5HCIiWDuY5ABopOEVIrbfTucIXS6h8eaL9+TzBaGAWYAFY90FmOE6Qb8 eFWlQmt8UQtszRvVQaZIPAvz0ju/x9bzDCYWKDf6oMfelTQan8wfb7u0B9Bfa09u0Dd0 qUc5mvdxeeE2xn9MhAYIAs/F0vPF5eTucCp5oxXLN9n5Mr12obbmemNcEDGj+lw6LsX0 8hSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Xbe1zafvLzFk0NBuZKfqZ6Cyl3GP1S5ka0zb2rUwC3Y=; b=V+CWk17kZZMeBpqSha8jQvKkIZvRoaeUI7C7YGldisLLc5Z20I5XRYIV93COzt9Rrq SfFbU+z4pGNYDktar87kQxdvesjUI2TMNty4TFvX6//E6Ydmy+dKKHbGJd+etJaz6q2j 0O1GsLmuEUKyT6N/CVZVDhlRmk0yCZGXspAHlSk4PD6BImF9P4F0+0Epj91CwFYwfjMW BJtpslULxImJYa99lK2zPXdTO6jEBfGKTSxGAcg8GPK3xpC9B8sWmN0mQACwesj5/CSh lqL0xN2U796ZBxQRUl0suIVbUDygZ3e7NXPUR7Oi/wTTTVnB3n3Q6rlBF6GHQR/ld56z 1Lxg== X-Gm-Message-State: AOAM530GMXBIMRmi/yzALN43B/FM22VMWUne1vceynPoYTAtnpQSRP3b RieoW4CM4aybVo+l3HTK4mE3Lw== X-Received: by 2002:a7b:c5c6:: with SMTP id n6mr1210948wmk.131.1604655302864; Fri, 06 Nov 2020 01:35:02 -0800 (PST) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id y185sm1395980wmb.29.2020.11.06.01.35.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Nov 2020 01:35:01 -0800 (PST) Date: Fri, 6 Nov 2020 10:34:56 +0100 From: Marco Elver To: paulmck@kernel.org, boqun.feng@gmail.com Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, kernel-team@fb.com, mingo@kernel.org, andreyknvl@google.com, glider@google.com, dvyukov@google.com, cai@lca.pw Subject: [PATCH v2] kcsan: Fix encoding masks and regain address bit Message-ID: <20201106093456.GB2851373@elver.google.com> References: <20201105220302.GA15733@paulmck-ThinkPad-P72> <20201105220324.15808-3-paulmck@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201105220324.15808-3-paulmck@kernel.org> User-Agent: Mutt/1.14.6 (2020-07-11) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The watchpoint encoding masks for size and address were off-by-one bit each, with the size mask using 1 unnecessary bit and the address mask missing 1 bit. However, due to the way the size is shifted into the encoded watchpoint, we were effectively wasting and never using the extra bit. For example, on x86 with PAGE_SIZE==4K, we have 1 bit for the is-write bit, 14 bits for the size bits, and then 49 bits left for the address. Prior to this fix we would end up with this usage: [ write<1> | size<14> | wasted<1> | address<48> ] Fix it by subtracting 1 bit from the GENMASK() end and start ranges of size and address respectively. The added static_assert()s verify that the masks are as expected. With the fixed version, we get the expected usage: [ write<1> | size<14> | address<49> ] Functionally no change is expected, since that extra address bit is insignificant for enabled architectures. Signed-off-by: Marco Elver --- v2: * Use WATCHPOINT_ADDR_BITS to avoid duplicating "BITS_PER_LONG-1 - WATCHPOINT_SIZE_BITS" per Boqun's suggestion. --- kernel/kcsan/encoding.h | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/kernel/kcsan/encoding.h b/kernel/kcsan/encoding.h index 4f73db6d1407..7ee405524904 100644 --- a/kernel/kcsan/encoding.h +++ b/kernel/kcsan/encoding.h @@ -37,14 +37,12 @@ */ #define WATCHPOINT_ADDR_BITS (BITS_PER_LONG-1 - WATCHPOINT_SIZE_BITS) -/* - * Masks to set/retrieve the encoded data. - */ -#define WATCHPOINT_WRITE_MASK BIT(BITS_PER_LONG-1) -#define WATCHPOINT_SIZE_MASK \ - GENMASK(BITS_PER_LONG-2, BITS_PER_LONG-2 - WATCHPOINT_SIZE_BITS) -#define WATCHPOINT_ADDR_MASK \ - GENMASK(BITS_PER_LONG-3 - WATCHPOINT_SIZE_BITS, 0) +/* Bitmasks for the encoded watchpoint access information. */ +#define WATCHPOINT_WRITE_MASK BIT(BITS_PER_LONG-1) +#define WATCHPOINT_SIZE_MASK GENMASK(BITS_PER_LONG-2, WATCHPOINT_ADDR_BITS) +#define WATCHPOINT_ADDR_MASK GENMASK(WATCHPOINT_ADDR_BITS-1, 0) +static_assert(WATCHPOINT_ADDR_MASK == (1UL << WATCHPOINT_ADDR_BITS) - 1); +static_assert((WATCHPOINT_WRITE_MASK ^ WATCHPOINT_SIZE_MASK ^ WATCHPOINT_ADDR_MASK) == ~0UL); static inline bool check_encodable(unsigned long addr, size_t size) { -- 2.29.2.222.g5d2a92d10f8-goog