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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55CA3C61DA4 for ; Thu, 2 Feb 2023 19:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF8066B0072; Thu, 2 Feb 2023 14:31:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA7E96B0073; Thu, 2 Feb 2023 14:31:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6F856B0074; Thu, 2 Feb 2023 14:31:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A51056B0072 for ; Thu, 2 Feb 2023 14:31:17 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 764D01A0FA3 for ; Thu, 2 Feb 2023 19:31:17 +0000 (UTC) X-FDA: 80423345394.18.9293578 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf12.hostedemail.com (Postfix) with ESMTP id 8C04F4002B for ; Thu, 2 Feb 2023 19:31:14 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nCOH74iY; spf=pass (imf12.hostedemail.com: domain of ndesaulniers@google.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=ndesaulniers@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675366274; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VBmv2nsbVE0gJmlmNoP7kbXDeT3T6G5d3aWuIere0+E=; b=RAOs5b3biJGW14tEUIbEBOc1Bs6kxoM1AmctfdHoU5sYeVIfkWMoMMD2qIi7MYhrSNLb+Y km8R3Hem/QXrhwUGUmGDjEEVxn2d+EEaS3uYrJcAZ6Xx4y2nFcLBQijpA25kHkEqhHuPpy 1p4aTG3OOSUn4pmw4WRRa/jCSniQ7T8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nCOH74iY; spf=pass (imf12.hostedemail.com: domain of ndesaulniers@google.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=ndesaulniers@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675366274; a=rsa-sha256; cv=none; b=1oFhvso2xWGKzCRLK42SeQyngA2IZYC+fifiElBFjuKWZhKJhQtgYFiMXDUKLb7v3u7IyI 2boUV3a73unJGKLctKof0n57a4UYoPGWqiirHezM5Crt0/MSNzLYJ1Pe7KEtDoYPZ+eVDw wEyVgIy7EOuz9g9v2+U2z/Rx7DsLseQ= Received: by mail-pj1-f42.google.com with SMTP id e10-20020a17090a630a00b0022bedd66e6dso6620760pjj.1 for ; Thu, 02 Feb 2023 11:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VBmv2nsbVE0gJmlmNoP7kbXDeT3T6G5d3aWuIere0+E=; b=nCOH74iYkqZBzZRH7PECt51DmW4zg54cN0sJnIhyDdeeLMF5czdkwL6AoLuPYVo0NG f+s3wsoVW7fwmsHiiM1ztoYR1Spy0eqq1VVa9YYxDXBbuH0YeFkotS1IjlQ1yTsLzE5A KUvae7dpP1F6lq+QJv/F1OthgAzuzGufocfj1yB8id/D9DVopcBxgZSGUlZ7mXc6CAkz TvTGxd3EN6rGygQj+Xw5K4bEZB5bwM6ywGXXasyiPZUOQ+EHnPUW2vvCDv7FdqVKnM8X 1NRCC3W1iWuXmFdwAghm3GOreXYYV8i0GmLNA+Ac7OPb3zh4zsCztwGAIIM3L3WvU9Cz 59iQ== 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:message-id :reply-to; bh=VBmv2nsbVE0gJmlmNoP7kbXDeT3T6G5d3aWuIere0+E=; b=HojXDsRBX0z3fdRyWi3WIX1da6No7h/4tzKan1qduaNLxMLCXWsurGqJ4wO1HmMEZ7 HjlXReRcdr/mSmR/Vs7DuwHs3JN5V9kRPGDiwA65sclhoXrMf4H+qrs/InlSluVNWzIP ogVbQeQIrMjv2QmcfQafA3aFFRk1kL1ZPGBPays5mrv+qgk6t8g1f9Sg1EYWLAtk4rZ3 dYWbar1atpE77AwV17koavOoRyLPGWMpmyjTTYHqJZZrr/Jk43aGbzddJ4tib7UPzorm IoM2b15PXjPW5rl5c9mSxYxL1naReFlm0yAi8HLG2KwnYLRUdtkQDjKAKxvRv2oHXIBM osWA== X-Gm-Message-State: AO0yUKUKkAfLUwxrCZdwxvPcOVYQMqomcLgM/nUuTmSU8q6UEfRK2Kpc xE+wqHZuVszFA+CfX6L/FKGkSf5P+RY5fYAjDXR6Ow== X-Google-Smtp-Source: AK7set8GBHiJ3Y1ulPBVw2wOkpjPhGLilq3YAf0r+/FgEFrYJlo2S8fLZaZMb0Qh1OoLbUoUdBBqZUYnIcao1uW1y4g= X-Received: by 2002:a17:903:120e:b0:196:44d4:244b with SMTP id l14-20020a170903120e00b0019644d4244bmr1807933plh.8.1675366272913; Thu, 02 Feb 2023 11:31:12 -0800 (PST) MIME-Version: 1.0 References: <20221101222520.never.109-kees@kernel.org> <20221101223321.1326815-5-keescook@chromium.org> <63dbf04a.630a0220.2608a.0149@mx.google.com> <63dc0a89.170a0220.49507.0091@mx.google.com> In-Reply-To: From: Nick Desaulniers Date: Thu, 2 Feb 2023 11:31:01 -0800 Message-ID: Subject: Re: [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators To: Ard Biesheuvel Cc: Kees Cook , John Stultz , Sami Tolvanen , Yongqin Liu , Vlastimil Babka , Greg Kroah-Hartman , Rasmus Villemoes , Thomas Gleixner , Jason Gunthorpe , Nishanth Menon , Michael Kelley , Dan Williams , Won Chung , David Gow , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Guenter Roeck , Andy Shevchenko , Paolo Abeni , Geert Uytterhoeven , Nathan Chancellor , Tom Rix , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, llvm@lists.linux.dev, Sumit Semwal Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8C04F4002B X-Stat-Signature: 59r6ctigjtm13dh5oxn3y8zrufby74iu X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675366274-247475 X-HE-Meta: U2FsdGVkX1+f0XO4KAbOKSPFX+O4vKMFvBKoi6AGlHD365shB7I5t+XSoMx9n9eDpZ/Mcb5IZy5GSUaLR47MI3V7bQDXkSnr0UNoKtcpicn5lzdeyOlAiF6bhsBhSJyagDWP7EYWXn1QxmC2Jp3srMMIk+M+N/TUYpAGfKTwZcN1UV8+fS1k+FNmBV1MaGmbak+pOhJEC/311BFORcHSUSNHZgxTAfKUx16HFohK3DCVgAcoAGKgUmY98B+ijBXDXhtLPHvyjHDe8VXNqL27xPSwOktWt8M+lOaJ+0+CtLK5fM25OhBuCdUXeKPMWIlBDM/k8+0n3nTKI01QDdDExgRZMDkT+dtRGwy37eBf1Imr/rF2sK5QJeL1cewESQtTFqUcYoDYgc3cgvuEmG9j2eIu2BnQntmoQ6+Tn6t4KjSkg2L24vAElyUOX0O8vpRUVYkl2KO0E/vABbEdk6xeBXIfJ7Ix0HbGt0hwAS6b2c+mULBU2ZzeMdJStGG4gGlwXwStd/3PlPJeJZ1cc8D2yYDI+wfGcd99YIzZG73ndARARqU5V1LFyGJlmMnHkl1gRfX/6fol6bw/J8mKGaNwg/BNTz8qh1RCpqmIGzx9VapMN/+R0I/sbSXSit1yxZwCH29PZbp4du8xyxMXZb+XFx0KcV3oniqXSbVnEjOy11by6jgL9EBN7dSF8hwkko2oYlzildAP+wycqRk5ubqFY69/+NTOawd4wlVp5apMyxohiekcfj60SneXBSDVRMA2JT3unlHi05PxHs0FIY9V4GJcojoF26OscnSZ0kvwMsL83TysowTz96KohtUn7lajcEIgT7d28bave7+6AX5xFJ7L7XDUzDmHlfCwdpE+0kX469CHg7qFPsAXYw4o0oSmWhjA9BSWTup6cPwl2IbxTbp8vYwBcZOh/C2VAOfMCtR8q3hoIfbCIu6YLQ5jNl1SRj9wv4VMZ0mXE75p0te Tt45/6SP H2jpfXIR1GqebYw7Rdm34uQ9yh3E2F/hvfSkTYGZKhZ+gEIt49+PfEjNSCkW5kPkBxyssIPHzueLfzTX4lfnh6Ukcc7B15wUtmhwqgTS76vFdXntUa3OYtKViRT2f5pojFlR6UJbksccfpU1Ym/JOKdIkZcBW+rRzSQWzwJ5JBy0YK1W9KsBU/iNxLrPRQiGsFBaf3xZySEBVoUqJ5/WudVrwqn+0xEAEX9QXwZXPQZ2RzKa3qAsgnUR8g1l3tAt0twrP9FKTodNBtROdRVDFHYiTfSbJjBi3RXQ8ZdslxXJ2psF0E2w1oYsySKqz3j+HoJC3hIqLXy3Qm2kLBsoxxb3aD6ghJ6SlgFvno6VxFfSOy6bF6jMHG0EQTbMgevqQYuo3mE9A/QpKSYoAF/+MWSBd0UxvJD3jbh1fefYzfJ3T+dFp4MfrmT2v0pgN8JTl6eu7e7Cb56P2HfhyNY7A9zZDpdFYz8f9axjT X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 2, 2023 at 11:20 AM Ard Biesheuvel wrote: > > On Thu, 2 Feb 2023 at 20:10, Kees Cook wrote: > > > > On Thu, Feb 02, 2023 at 10:56:29AM -0800, John Stultz wrote: > > > That said, making sense of the error message isn't completely trivial > > > either. I've been seeing a few cases recently of some of the new > > > compiler tooling (I pinged you earlier on a CFI one) causing errors > > > that developers aren't really sure how to address. I know sometimes > > > it's not easy to surface the errors with context to what was wrong, > > > but at the risk of intense bike shedding, is there some way to provide > > > something like "Likely array bounds error" instead of just "BRK > > > handler: Fatal exception"? > > > > Yeah, this is a result of the size trade-off that resulted in config > > CONFIG_UBSAN_TRAP -- there ends up being no message about what went > > wrong. I'd really like to have cleaner handling of this -- perhaps what > > was done for KCFI could be applied to UBSAN as well, though this is an > > area I don't know well myself. (i.e. encoding "this was a UBSAN trap" > > in the trap itself.) > > > > Sami or Ard, is this something that could be improved for arm64? > > > > -ENOCONTEXT, so I am going to assume this is about runtime > instrumentation that needs some kind of 'panic' function which it will > invoke if some condition is met that should never occur? > > We already use brk with different immediate values in the opcode, so > the arch layer already has what we need. Is this a limitation in the > compiler, perhaps, where it always emits the same brk opcode? Yeah, we'd need to update both the compiler to produce the encoding, and the kernel to recognize the encoding and do something special. -- Thanks, ~Nick Desaulniers