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 52712C05027 for ; Thu, 2 Feb 2023 19:20:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F2D36B0072; Thu, 2 Feb 2023 14:20:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 97B8B6B0073; Thu, 2 Feb 2023 14:20:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81CFE6B0074; Thu, 2 Feb 2023 14:20:33 -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 6F01F6B0072 for ; Thu, 2 Feb 2023 14:20:33 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1385F1A0F7D for ; Thu, 2 Feb 2023 19:20:33 +0000 (UTC) X-FDA: 80423318346.10.2FA757B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 238C71C0019 for ; Thu, 2 Feb 2023 19:20:29 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NMChNx5w; spf=pass (imf20.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675365630; a=rsa-sha256; cv=none; b=a4nLkIum3T4FY5pxp2EkYqpvX+FpArYh4CV4ke6jrS9K0iAEybOHJ2XRouwa9W9tTok40L S7ez4ePsRRTkCcgkQU+MzyZJVy2SNRbb8eW3ypFtk/7IqKGROElYa88QH5b+xkNaoFM74g /qa3pfibklmLenF34DAYku9dNZRMsp4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NMChNx5w; spf=pass (imf20.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675365630; 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=zeOWitWXsg4Wd/A+g+k4zcRCVIgeX/b1ikHi9Y67Pm8=; b=ssVLFu0jDLSyM6gFfhXDZZMOPthel/VrimxpsVInKkzS6TnklkiAWusZ5s/r4gXK4R8FF3 TzzR0Uj4xX/7gd//UxZ7SFfKsbDM61V1VDJvGLBXvLrirA35+Pv+5SKC3eYn/pKGU8GQBP 7l4/bJwF+FKEjYKCxCOExOA/OzXOO2Q= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 17F0761CAE for ; Thu, 2 Feb 2023 19:20:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C4B8C433D2 for ; Thu, 2 Feb 2023 19:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675365628; bh=GW+/PPknO/L/X81AhOAvMB1ckLEie9QjfLbxFOYKFMw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NMChNx5wMCGdw0bzTAy1Mx4u01KlZjQ31d75GLSihuJkXnvTwNjEDsrqfdXGk4F6t U8tReWXZranGN0JhcHJpl/g9kfxHN8+Cf0kRM6GmXWEa394DvQwfvxlfhIehuGaA5e 1Y4wn+ODaiIuepqZDbkqV6L0o8OVPh3hbJbjKaMwuSkkulN7BuBB3LhQYBlJITfq/E uWAHSxxKQCkrr4Qa6ZSpgLqdsLvA/e2m3YY253RE3ByH6fBOnBpizYeSF/nDl831wE 8Ck5xgqVSXGzJjEXXb+f/GnzD70sVDV6E1w3eaw+1t2sw49E7zTV9txFnj+6eQOC7S giW7hqHMiYgwg== Received: by mail-ej1-f46.google.com with SMTP id m2so8914269ejb.8 for ; Thu, 02 Feb 2023 11:20:28 -0800 (PST) X-Gm-Message-State: AO0yUKX5FakSbWrIN9eBR7Xkvl4pg0eu9Vfv//Cm4TlYINigDqlVvPWs JIb0fYg80OOUeEC8vp97+cogd8kPm0ozERsNJKs= X-Google-Smtp-Source: AK7set8f/y1tDqDb8um8dkpVuXWlMd7cPiWojFc/RDUlBXn9F2x4UAKk0tGsfdESMBoK9BDxmjY865izBQ0xCKgQYCc= X-Received: by 2002:ac2:5b9c:0:b0:4d8:767b:8b6b with SMTP id o28-20020ac25b9c000000b004d8767b8b6bmr1440315lfn.63.1675365616510; Thu, 02 Feb 2023 11:20:16 -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: <63dc0a89.170a0220.49507.0091@mx.google.com> From: Ard Biesheuvel Date: Thu, 2 Feb 2023 20:20:04 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators To: Kees Cook Cc: 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 , Nick Desaulniers , 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-Queue-Id: 238C71C0019 X-Rspamd-Server: rspam01 X-Stat-Signature: bfyudyztscsc7s98zb3f9qp54cu81y8i X-HE-Tag: 1675365629-706295 X-HE-Meta: U2FsdGVkX1+mPzpNQfsvpjoPxCA/7Pqa4k/KeCBwEu+RlX2niYug6Ir0Kk9/lwg7zU18FrPZJUI1m7ljkWFuGJeAjuVrGjMKYz69v2grtkc3oMFP3eThwHmrpEa7D0ClXja38CXHmwpMheJFe+pzRzqbViUfT2ktd96/kw2/JGLmgcsBE+YCQsga6Ys6jgcEyqJLcU/8Np0JDNsYLqvwZxQWYTsPfKTfgy1I0kcpbJu4i05WfbOAyKieuor+BAtok5V39lPrqDJXMJAqqdfoo3VLIzZTxAYe2ioTWsEjWZNuDaIEcNi0OHS3HgLIjeZNv7cVPS4EahXd+3Wwe67hrQ4d2YOx9m8wOfZmec9RLV1n7WI/5e29wsrBEp4JPkAAMhPZZSjtQVVnVS9qnajZvHpnoOGsq0a8SlWFS6WSwZkTxcKXxuZwh5J9EaBftSdEhQafQH77yzO+FUno+rUK2eBxvoqxzjVvOS9wlo68n760ZBnruV6vBLj5yvfoQpMaqR3nV0T5hyhJEiCX9hF1HMrbANzgd6xtS699yRoRx88NbtstnBW/Sv4w+2Q7kSeJx9q9MzvaQJHqCq/aMWuOOZmOvmHx3yUa7xHrIrgcVxR18En7gEejbzrxTz8qfH+myQRm2V1zMH02nI6c9njoqWGaos0b8Ixm55+gXG2vMa59S5/DxQt7+n+nGXeMN7+nhNwl+8ds1rqFJuyTp+y6BpZTKIzIDxjTJ13p57DZ9njDf5gsU4OtCMhfQoAvEzziMdKK/a50ahIKO+ADJ1/hRL7WgdT9TFglz35tVaJcybwPz9q0u/rpFE7k12pmGmqxdN4ekCD1GGaNPJ1o+A5mTys9GTla+Ed3OtN2qKw+VO6YrFlZ5uzKA6hnaWxXMCstIkwysa2dB2v0vDZmgYotFVuiSFzfjwTfYXsRW7UR+QgaXLB3MLO7OeY6oW8JI1sYQ4vdHs4wT+SHkBVQq/L lkgSDCeC EqNtaiCeQmnr6PPMTXqCiWSWgholxlWKoKiJ+w0ok5CAYnkZMYXsSfuM46pHwSqRa/2RH2INgacRv4zOmdqxyIw66nRGFZRXEgFh1dl7qhA9fll3AwlmTY9uzQuwfd0xr3soNi+dql+kwkUyvGwjJgeUsoTzSiMFP1LnOT/JLGkD5L5OU1qy/z9uUN8tafgueVTpBgQ0VOOVnr5cd14aViqeh+C0eVxR2GIvSnx+tlexs6OhOtmBldDx6PlkyZvHh/sJF2E8dKRdNb+X2tyS9/igcWm6Tao3FddfWm6a71w5+hvmZiLX7omR1yEfYA9HGrF1RaCPapfHxV4TyZMPDr5g6WdswcKSjob4OuwQtQY+H2j+9+8P+r3S5jBlXch1SjLyk6i0tNYAl0WBG+t/SC0uKRJlibNLggo5kgkS9MKvjjfFxiQjAmSDmgAuTVJ0cIAvl2xIJGR2kJOdqZRhzyjJfSQRthVs+BPeJPNcA46he6BpvY+6GG0vrs3xifmU0Ahbr 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, 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?