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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FA2EC04A95 for ; Wed, 28 Sep 2022 17:09:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234308AbiI1RJi (ORCPT ); Wed, 28 Sep 2022 13:09:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234305AbiI1RJf (ORCPT ); Wed, 28 Sep 2022 13:09:35 -0400 Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0BFE5FC4 for ; Wed, 28 Sep 2022 10:09:33 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id l14so8533691qvq.8 for ; Wed, 28 Sep 2022 10:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=7vQ2L03NmZjTjKW7aYlNCJZqth3/yEDQLyW9BQRTAy8=; b=A+bgUQTLuISMRGKf3gH1kVvGmP3b/AaIOap7gHgA/PD0nbgpIKholTwlPXLri1af0K cnXmQYCXr6Teuy/PYE/inGfAxECxd/mCvZF/wqKa528cfQv970CHoLHSzLvnxIGoeg2I Wt438dq+Wr6ck6v+tRyZuqUTQ439HqIxvfrIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=7vQ2L03NmZjTjKW7aYlNCJZqth3/yEDQLyW9BQRTAy8=; b=5ap+8CwUgsyJZS2p0VVi3MyV7eWM4pVtxSNFdkY+3mJIjaGo5RoIs6P3VUHX0vR+eB n7tIm3UuoIcg+Bp1h2pfqMntUSi7pYFs1/hGjCgGvBx/7eqi6Z1IVJqTLeJWAd2NDrPT dhwfBBe/HsyxZLiEz6IibBx18e/c5UVx9JXPnarE2M5w7UhdB//8lh9TYPziIbh1L2u+ LEJWrMaCe1BD6WVguvH04Lw6wKyzCiHTaXJ3br5993oIk/mzoThddy/rn/JWEUwN00T8 yGZrAyCkTbskTxcOUalyH/eEbk9kAdWGqwpxFlb+OBQPQsvebG6wGiK/b4JtOV/bXuMk P8AQ== X-Gm-Message-State: ACrzQf232q103XnnCheESk+w/htvsWQ0Jw9KobZUuQLCfXO3DFnAfRXb oFWh4QCm0xxcr2mgCqPSEHHjT5lMnPmgLg== X-Google-Smtp-Source: AMsMyM6BnB+40plWP0KiJE53a+L+gZ6yMBy7zuCxUGhBQXbnc/qkWcZvg/3B4CgBBkJepxMKuCQDVA== X-Received: by 2002:a05:6214:400c:b0:4ac:8066:991d with SMTP id kd12-20020a056214400c00b004ac8066991dmr26047451qvb.112.1664384972443; Wed, 28 Sep 2022 10:09:32 -0700 (PDT) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id bv21-20020a05622a0a1500b00342f8d4d0basm3383542qtb.43.2022.09.28.10.09.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Sep 2022 10:09:31 -0700 (PDT) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-346cd4c3d7aso136812647b3.8 for ; Wed, 28 Sep 2022 10:09:31 -0700 (PDT) X-Received: by 2002:a9d:2de3:0:b0:638:e210:c9da with SMTP id g90-20020a9d2de3000000b00638e210c9damr14921820otb.69.1664384960424; Wed, 28 Sep 2022 10:09:20 -0700 (PDT) MIME-Version: 1.0 References: <20220928081300.101516-1-gwan-gyeong.mun@intel.com> <20220928081300.101516-6-gwan-gyeong.mun@intel.com> In-Reply-To: <20220928081300.101516-6-gwan-gyeong.mun@intel.com> From: Linus Torvalds Date: Wed, 28 Sep 2022 10:09:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v13 5/9] drm/i915: Check for integer truncation on scatterlist creation To: Gwan-gyeong Mun Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mchehab@kernel.org, chris@chris-wilson.co.uk, matthew.auld@intel.com, thomas.hellstrom@linux.intel.com, jani.nikula@intel.com, nirmoy.das@intel.com, airlied@redhat.com, daniel@ffwll.ch, andi.shyti@linux.intel.com, andrzej.hajda@intel.com, keescook@chromium.org, mauro.chehab@linux.intel.com, linux@rasmusvillemoes.dk, vitor@massaru.org, dlatypov@google.com, ndesaulniers@google.com, trix@redhat.com, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-sparse@vger.kernel.org, nathan@kernel.org, gustavoars@kernel.org, luc.vanoostenryck@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org On Wed, Sep 28, 2022 at 1:15 AM Gwan-gyeong Mun wrote: > > + if (check_assign(obj->base.size >> PAGE_SHIFT, &npages)) > + return -E2BIG; I have to say, I find that new "check_assign()" macro use to be disgusting. It's one thing to check for overflows. It's another thing entirely to just assign something to a local variable. This disgusting "let's check and assign" needs to die. It makes the code a completely unreadable mess. The "user" wersion is even worse. If you worry about overflow, then use a mix of (a) use a sufficiently large type to begin with (b) check for value range separately and in this particular case, I also suspect that the whole range check should have been somewhere else entirely - at the original creation of that "obj" structure, not at one random end-point where it is used. In other words, THIS WHOLE PATCH is just end-points checking the size requirements of that "base.size" thing much too late, when it should have been checked originally for some "maximum acceptable base size" instead. And that "maximum acceptable base size" should *not* be about "this is the size of the variables we use". It should be a sanity check of "this value is sane and fits in sane use cases". Because "let's plug security checks" is most definitely not about picking random assignments and saying "let's check this one". It's about trying to catch things earlier than that. Kees, you need to reign in the craziness in overflow.h. Linus