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 5D036C05027 for ; Thu, 2 Feb 2023 19:50:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CC366B0072; Thu, 2 Feb 2023 14:50:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 87C6E6B0073; Thu, 2 Feb 2023 14:50:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76B166B0074; Thu, 2 Feb 2023 14:50:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 663E26B0072 for ; Thu, 2 Feb 2023 14:50:24 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2E1E181017 for ; Thu, 2 Feb 2023 19:50:24 +0000 (UTC) X-FDA: 80423393568.14.A2AB004 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf22.hostedemail.com (Postfix) with ESMTP id E7F61C0012 for ; Thu, 2 Feb 2023 19:50:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Nk/tlhkD"; spf=pass (imf22.hostedemail.com: domain of samitolvanen@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=samitolvanen@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=1675367421; 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=1fO/hIqmJopkgUvbt7bySSxbzKni1x3M08W8IjYrXvw=; b=pGFTEHmBPphh+BBjadUgsGXQcPjxo4P4T07AJvIwEtNP+XRUaY4uBOESlwfrJPHyEzh/xw 5ahzsdXS6MHOnP0mvffI3/ZiClVlOoxs58b2eXJYJcBIL77Wm1n7lhDKquZEUqZiVTT3uO KDRfrls9xu2zdmbi/KdZkuTv289zLSk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Nk/tlhkD"; spf=pass (imf22.hostedemail.com: domain of samitolvanen@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=samitolvanen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675367421; a=rsa-sha256; cv=none; b=zN5uXPdvuZiduiMcdvzR6cqM/zA4C+ffr5n5NieM9G+5dlocwWJfKzqjJZ0ogUz4D+6Oe+ jnj2kNX4Myl+dhtfNhxO2TFgAKQUDMpPv+wNGjbyp03REMhCaimDTWdW1dYmcFyU3Ahh5G ChKHoSdCjqDrRvSKfRTJl1Uqez4GfiE= Received: by mail-ed1-f49.google.com with SMTP id cw4so3131588edb.13 for ; Thu, 02 Feb 2023 11:50:20 -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=1fO/hIqmJopkgUvbt7bySSxbzKni1x3M08W8IjYrXvw=; b=Nk/tlhkDi2nPmK20+FASBstHtUCa++2jP1YPu64tTbp3j3pqbJ0FhZNMd9W6O/a32w 2702aGUveoLKKYg4Wz9BBaBDf+NJvysDeNqSAGSWSJ07P4eTbzKo0Rwa3aMkhAQxY2+F 1MuOUCWx7KFKSAxwyJYJAmxNuTnreiHihc2IInKMdOcgOjXALj9XEv21FC1ge+kANhkp YEEkEqeNhqvTe3dq5QierAgpSoUa51Hyi7bCyLj44tPdPbuo9VtEHsO2i1Ftg5i1QJVN obIu5YHE2PQ51xkm6b0MUmS1UxP5e6gvzREiYWGXo1d+ToD6tUPwm1BGGZXzJhsQxr53 pGaw== 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=1fO/hIqmJopkgUvbt7bySSxbzKni1x3M08W8IjYrXvw=; b=y2Oa64LWDkwqUgZsR6x6SaxGzihTKrJVeXlMfNA9V6mBL1nMo/RQSCkGM5JPrrWVAZ pdINkH6TWPjd1QNWmj8XFAEDBS78xcTF2RKj13Y1pSnJGzv/bqKNRHBiELU+EwgCdypq q0lvORMPTh1pVz/81z1xvE0vkm/Vh2pRB+Y8vdlXW5BAIyyV9AYRHA4KVhqjZpmcHMnV XKg/tZV3z0ZFTii+KiZ7fu+EsXOa9wUd2SCxkGWpK1A0rceOq5Urllrr7CVZUPXQXEl0 hdNimB/h6tddpNG0wHIxZzWARpUZRlNsNXyuPVJScp6VYYZypUepw1K9JQS95K7ADv4y 7LgQ== X-Gm-Message-State: AO0yUKV+THgRo/IP895mAngJzoS6mIpqNrhSgAG7Uu8twPT+9cuKB4oa S9HN7wPrSXH4leM4vuSSweIrVn7IAZAHMKsh1wQE+A== X-Google-Smtp-Source: AK7set/lkyA3ZhhrgMGS/eLjMhSHYMmy+wZ9RvJpPhhZSHTl/p53byYoaa18x/kaSuurcJlXmSo8kQp6GRUsvPNR/yQ= X-Received: by 2002:a05:6402:2489:b0:4a0:f071:3656 with SMTP id q9-20020a056402248900b004a0f0713656mr2440374eda.81.1675367419383; Thu, 02 Feb 2023 11:50:19 -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: Sami Tolvanen Date: Thu, 2 Feb 2023 11:49:42 -0800 Message-ID: Subject: Re: [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators To: Nick Desaulniers Cc: Ard Biesheuvel , Kees Cook , John Stultz , 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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: id5kp56xagchim675tgyd6zxjerg1tex X-Rspamd-Queue-Id: E7F61C0012 X-HE-Tag: 1675367420-715250 X-HE-Meta: U2FsdGVkX18r9JCtqaAvBTyYXGoMrp9mtKQ5yFQrlzFiHGNEN0aopUjEMYKUD7e0MswQmP/PZ+7vEidPGVvJ0Y3cybhUxqRcwK4gIpOvcVKsysPF2xsElPIaHMy/Xux2A7UN4hpGSgtalOq51ebT+8sLLwqdDk0MIthZTf/m3/noRaHPxwoz5cekITQWWjr6O0qvOeXrhWFNLKc3Wy6u3GozFwEKJVEQZjrLR3xShegulZoMT78AFIYb2ICwdVFJzxXrLS3Gl3iRuIhGe3vJOM29oHsTNY+JbrZVfVAqSiUXZskKIMmwKgcJ7BTTKOaDvgOxLg5lERa2ah/dHLKNkHi51pWbrX2CPNYpARSvGLY1xy5vgK3qq4Pt2SAy4spjFM7TheLiJal7kZxvdGLlYK4b3axEOnNi6IR/rKwJWWBF07Xezw7NcvEYqtlh4Mc8ixYV3dqsAbFZ/KczAuQDri4L1FCH11KXrjZQTiQlwnP0Dvbqq+zqgMtk+Vq9fplFxlrrCChGU5u0ciBtyZhMoUbtZbDevMY7pOAiZbZkBDlOmnPAH0QPaS2JiizpwtBNca2c+TpT5oN5PSw+jMqgEhZOt5isMO/sbPN5tBvXdMdmmYmTbgizL1KrGVDlyc1i6J1/aGR0yoqEj3iqbtWLwHKN1A7JJdzOjeXl4Rq30ZrutzDkhUIH1iZBmD9wFNrRIuhFAkGntalVcYRwWZ0Jxf3o2B2WgkEQ2ni3xhw3RGsSxr0uDUHFItPs2+OfPqpySE2Xsc3m6bPlnxh3yukHC1rQhxqQYuaZ8aWxDLXC0AwEU/BAGrbqNP3KaLjJH0c5HFeDTpBJ7IFp9d4AoUeVnympxOvXpcJq5Z9LTFZ0O6ncPPcBbnJMVdiCbWEzEStqnlI6CEuORpF5E1GiDnGUPLi9j4svIh7/rEetc2X3CK7UuC233y9kYFC8Hm/6uJCGz5/CJ7VpAGxDuEqwTAR GjhDh84D sli2KulnLaU5EeWzZvK80HHPt3JLny5i8NksWQyiDN6OOtffdT8mlx+u+f/rxr5IYnoXRIJVb6/9zEqP8sJJVrpmJsF5tOo6Qf93wvpIfkIMX0JQUHmFrpiV3+a25+K4PN1+/L9jupDbHoa6Ca9hJ/gYnBUrXf0ZSQjhiwg4LVaAabeHib915T0se+XXsMYRPDuIJ7phs9RokOu+2bY/dE5SXegdBU5BBmvdFeg3oJETKhwt56EbOjkFb/GEBfsRVnlAp1RL2VtKvhcudF2Eib2OHEZnkDaAU0m5AwgfZNR8i046K9Ft1/2B90TpDRatVONtJKUVMQJoH8A8J9QNSQZEq1EOvsH08/Aa8HWTxwB4jzkzDYA6WGLZ2vXAOw6JnqanDzwRGf5iLQXjmx8baiKqPs8cC8qiVr9ZDFzvWCdh/jcxE+9PzfLEEEUI/0CrNNu+rYFTdIUhEraLoLSri7fg0dIQSClb7924EO8ClJnO9NWr3PtQxVS8xPw== 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:31 AM Nick Desaulniers wrote: > > 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. A quick look at Clang's source code suggests that Intrinsic::ubsantrap already accepts the handler ID (from the SanitizerHandler enum) as an argument and the arm64 LLVM back-end appears to encode the value as an immediate for the brk instruction. I didn't confirm that this actually works, but perhaps we just need to teach the kernel about the possible values? Sami