Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp952178rwb; Wed, 14 Dec 2022 05:01:08 -0800 (PST) X-Google-Smtp-Source: AA0mqf7a6nKY9+H12J4aaWIKAnCWy8MD7YFxWnPYVidt0LfP+v9t6O/xyviM7yCxRAUSxLedFWvM X-Received: by 2002:a17:906:49d2:b0:7b9:f9d8:9554 with SMTP id w18-20020a17090649d200b007b9f9d89554mr20621267ejv.40.1671022867824; Wed, 14 Dec 2022 05:01:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671022867; cv=none; d=google.com; s=arc-20160816; b=zDxJNKV8lnH31iEWyCyB2SWR82uMnP+Kj+TTVcyJi/7aTOLgArWSjRYkMXbOtFO9PH 4Ge4Iz5Rmo5V0MX4dCpu+saoXQBUg46QqrIR3mx5mDn05vxBnWsl8A1/40gVBggvIam7 DzOHQ2ATmt0FFTVKBv6ftVILzm8KuCPv1JguVGFH4fQWx7KtgT8Cd5oferKbkptRUnmo uJxpkM2ob8juNGR8JSx5enEVJSQtBVmVz9HOuH96GFH1rcxP3cZgumuw509oEL/QW917 mJqLuokjKx+2JvTyfr6wq0l782LW7BiZPgzNlpAQLCv+fOpzHI6t38FcK6P7LQO3uuP7 J5Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=DKcx+4YJjVwTyK2QcuOyj4PT3DlLaSSyyosJCyUE7i4=; b=elBfvvElk2vTKrZvAMrnywzyXp6GyfDqgLnKCeyHiYy+0ANGh50o0S0rTKCYjRwKim 28WZ9zrHgNY7vnBKG/GAzO9hpBeqRn5vSdxomlMTntdhskXFcnmbB9nlvMQNPaUOM/lj DXOhGXRZfDgeuQHyQ4sB9VLqgO5DYHwhXxrg06Ol6UL6O0NaUwIqBjeUBirQt089Pt9C gbd0sNuz+aXuUOIlaC7B1HcB29CnqpVDz1DKNfLdGp54e07Jr0ry6G1mDu05AryHvt2l tqPUb+e1EQ0YjZqMgJjNe1uN0OmHfe2nIOoXtk4lf5xP4DPWRNJSG0o/qjW7Rx0c8b5M 5TcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gb15-20020a170907960f00b0078db1258ae9si11135283ejc.555.2022.12.14.05.00.46; Wed, 14 Dec 2022 05:01:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237778AbiLNMuw (ORCPT + 70 others); Wed, 14 Dec 2022 07:50:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236681AbiLNMu0 (ORCPT ); Wed, 14 Dec 2022 07:50:26 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A686BBC9; Wed, 14 Dec 2022 04:49:56 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E8EFAFEC; Wed, 14 Dec 2022 04:50:36 -0800 (PST) Received: from [10.57.88.237] (unknown [10.57.88.237]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2339E3F73B; Wed, 14 Dec 2022 04:49:54 -0800 (PST) Message-ID: Date: Wed, 14 Dec 2022 12:49:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH 4/4] remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headers Content-Language: en-GB To: Manivannan Sadhasivam , Sibi Sankar Cc: andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org, agross@kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, konrad.dybcio@somainline.org, amit.pundir@linaro.org, regressions@leemhuis.info, sumit.semwal@linaro.org, will@kernel.org, catalin.marinas@arm.com References: <20221213140724.8612-1-quic_sibis@quicinc.com> <20221213140724.8612-5-quic_sibis@quicinc.com> <741b64c2-0b09-6475-5736-d2cd3e33c34c@arm.com> <20221213160722.GC4862@thinkpad> From: Robin Murphy In-Reply-To: <20221213160722.GC4862@thinkpad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-12-13 16:07, Manivannan Sadhasivam wrote: > On Tue, Dec 13, 2022 at 09:27:04PM +0530, Sibi Sankar wrote: >> Hey Robin, >> >> Thanks for taking time to review the series. >> >> On 12/13/22 20:37, Robin Murphy wrote: >>> On 2022-12-13 14:07, Sibi Sankar wrote: >>>> The memory region allocated using dma_alloc_attr with no kernel mapping >>>> attribute set would still be a part of the linear kernel map. Any access >>>> to this region by the application processor after assigning it to the >>>> remote Q6 will result in a XPU violation. Fix this by replacing the >>>> dynamically allocated memory region with a no-map carveout and unmap the >>>> modem metadata memory region before passing control to the remote Q6. >>>> >>>> Reported-by: Amit Pundir >>>> Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for >>>> mem ownership switch") >>>> Signed-off-by: Sibi Sankar >>>> --- >>>> >>>> The addition of the carveout and memunmap is required only on SoCs that >>>> mandate memory protection before transferring control to Q6, hence the >>>> driver falls back to dynamic memory allocation in the absence of the >>>> modem metadata carveout. >>> >>> The DMA_ATTR_NO_KERNEL_MAPPING stuff is still broken and pointless, so >>> I'd expect to see this solution replacing it, not being added alongside. >>> It's just silly to say pass the "I don't need a CPU mapping" flag, then >>> manually open-code the same CPU mapping you would have got if you >>> hadn't, in a way that only works at all when a cacheable alias exists >>> anyway. >> >> only a subset of SoCs supported by the driver are affected by >> the bug i.e. on the others dma_alloc_attr would still work >> without problems. I can perhaps drop the NO_KERNEL_MAPPING along >> with the vmap/vunmap and simplify things for those SoCs. >> > > Or perhaps revert fc156629b23a? Oh, indeed, if it's already self-contained that's even neater. Basically that whole commit is based on a misunderstanding, doesn't actually do what it thinks it does, and you'd be far better off not maintaining the extra code. Thanks, Robin.