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 A16D8EC8738 for ; Thu, 7 Sep 2023 16:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232357AbjIGQAp (ORCPT ); Thu, 7 Sep 2023 12:00:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242115AbjIGP7V (ORCPT ); Thu, 7 Sep 2023 11:59:21 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 545474682 for ; Thu, 7 Sep 2023 08:48:37 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F471C116B7; Thu, 7 Sep 2023 15:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694101302; bh=zePQdjSjpAxHSlG2N1mjiwP8rP/tzCKfSbAd9oQ6Whw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C9sc8ylv5PC3Fa2MHN441gSLzenPZ75yZ17Ocgqqeh/ncVZm7JYfPUuUbjKKjZtca dJqKnkC/u+GpvQ1VGD9IR8s5lBxpOFWWDWPbZ9ehQw52LuFMMW/ql7S2JfeuyLLoQi pTaPBNVm02vqXoKvKGRJfTqLv29atzTzsD4W/FqfrHE1yKWH40BOAmh5ONJKSGCAK3 FKwUO4eHnuNV2ldy1NVdNGqvGmg3fO1BU2foMb3yIRSeJ/AWi3mUx9vbxk0ZIKlreu Ju6Mwm1pLzuAkHHSaFn9oKhkhkOqlUWENH4Fz6RugMaQWnHvrYTJUHX2rUA2PLUioa cxEJtePsL7KaA== Date: Thu, 7 Sep 2023 09:41:39 -0600 From: Keith Busch To: Kanchan Joshi Cc: hch@lst.de, axboe@kernel.dk, sagi@grimberg.me, linux-nvme@lists.infradead.org, vincentfu@gmail.com, ankit.kumar@samsung.com, joshiiitr@gmail.com, gost.dev@samsung.com, stable@vger.kernel.org, Vincent Fu Subject: Re: [PATCH v2 1/2] nvme: fix memory corruption for passthrough metadata Message-ID: References: <20230814070213.161033-1-joshi.k@samsung.com> <20230814070213.161033-2-joshi.k@samsung.com> <20230905051825.GA4073@green245> <20230906154815.GA23984@green245> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230906154815.GA23984@green245> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Sep 06, 2023 at 09:18:15PM +0530, Kanchan Joshi wrote: > Would you really prefer to have nvme_add_user_metadata() changed to do > away with allocation and use userspace meta-buffer directly? I mean, sure, if it's possible. We can avoid a costly copy if the user metabuffer is aligned and physically contiguous. > Even with that route, extended-lba-with-short-unaligned-buffer remains > unhandled. That will still require similar checks that I would like > to avoid but cannnot. > > So how about this - There's lots of bad things you can do with this interface. Example, provide an unaligned single byte user buffer and send an Identify command. We never provided opcode decoding sanity checks before because it's a bad maintenance burden, adds performance killing overhead, couldn't catch all the cases anyway due to vendor specific and future opcodes, and harms the flexibility of the interface. The burden is usually on the user for these kinds of priviledged interfaces: if you abuse it, "you get to keep both pieces" territory.