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 X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 215EFC433E3 for ; Wed, 8 Jul 2020 04:30:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01CFF2078A for ; Wed, 8 Jul 2020 04:30:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="gwkq4+Hl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725446AbgGHEaj (ORCPT ); Wed, 8 Jul 2020 00:30:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726206AbgGHEaj (ORCPT ); Wed, 8 Jul 2020 00:30:39 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1BA9C08C5E2 for ; Tue, 7 Jul 2020 21:30:38 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id g75so1463377wme.5 for ; Tue, 07 Jul 2020 21:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=9z8AqNAtfLqJboxfTSuy4+9Gg/kN9QYsVqfQLWbeo4w=; b=gwkq4+Hlakm3izkfm3Vx8ZZCM5LOzO3cymjOSh4+vM8T7cBwdjsaTUVd9kq/x6E+Nh LNC4usHx3RpnjI9YfPVuOYlIHMxSq1nB5UkuqJzdB3PaMh+PFXIlNStED6a1DCPIfivL ZGphzvNanNKVijraSFJb+UugoBCX9/HxIAv7Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9z8AqNAtfLqJboxfTSuy4+9Gg/kN9QYsVqfQLWbeo4w=; b=TFpY3O9FbZjeQIfr3hah87/+eKkxWi2U9mVFOLi41h5JZlCCRBQ0OIwonqEgD0+awp THsvkgNJsmlJZqPzRtS8Uhgll02MvzCrZ/FtT57D5nIXN6WvlQC77UFFA4YjszVv3B83 05LbRZKdVD4ehiAHSkGujesXJ6fGoRMFeF9+/dI4rlpf2aVN1HdCXDdTTZ0kkGywOPFS sJYxtKS7npTJ0GQwsI/nParUB5QBAtgzOkG9BPxUHzEyleYS46W6BeOfMBnQ801T4bCj Y2oOtYAhBc2l7qt7zkJD6zjEw7DDV4Kno0XwjnNUvM9XhZ2awedKwkRKPAqLboh7SCnj 0AQg== X-Gm-Message-State: AOAM531aO6GYnzvX9Gz/cexEN4AyhnNikrn2lFiyZAQ0o10U3UDY7AE7 8WCGCRCXSdQYradDv4TpYuCB2g== X-Google-Smtp-Source: ABdhPJxz1HCKFHKGJAHeBxv2ayO0myaozG6pLXUA04b6prEWm0Cz5Rezi42VTrPu7hajJjMaPp0QIA== X-Received: by 2002:a7b:cd09:: with SMTP id f9mr7627559wmj.160.1594182637061; Tue, 07 Jul 2020 21:30:37 -0700 (PDT) Received: from [10.136.13.65] ([192.19.228.250]) by smtp.gmail.com with ESMTPSA id q1sm3577207wro.82.2020.07.07.21.30.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 21:30:36 -0700 (PDT) Subject: Re: [PATCH v10 7/9] misc: bcm-vk: add Broadcom VK driver To: Kees Cook Cc: Luis Chamberlain , Wolfram Sang , Greg Kroah-Hartman , David Brown , Alexander Viro , Shuah Khan , bjorn.andersson@linaro.org, Shuah Khan , Arnd Bergmann , Mimi Zohar , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-fsdevel@vger.kernel.org, BCM Kernel Feedback , Olof Johansson , Andrew Morton , Dan Carpenter , Colin Ian King , Takashi Iwai , linux-kselftest@vger.kernel.org, Andy Gross , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Desmond Yan , James Hu References: <20200706232309.12010-1-scott.branden@broadcom.com> <20200706232309.12010-8-scott.branden@broadcom.com> <202007071700.C567BA7B@keescook> From: Scott Branden Message-ID: <400ebe0d-6b04-a211-7d80-cc8b0bf4d7df@broadcom.com> Date: Tue, 7 Jul 2020 21:30:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <202007071700.C567BA7B@keescook> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 2020-07-07 5:03 p.m., Kees Cook wrote: > On Mon, Jul 06, 2020 at 04:23:07PM -0700, Scott Branden wrote: >> Add Broadcom VK driver offload engine. >> This driver interfaces to the VK PCIe offload engine to perform >> should offload functions as video transcoding on multiple streams >> in parallel. VK device is booted from files loaded using >> request_firmware_into_buf mechanism. After booted card status is updated >> and messages can then be sent to the card. >> Such messages contain scatter gather list of addresses >> to pull data from the host to perform operations on. >> >> Signed-off-by: Scott Branden >> Signed-off-by: Desmond Yan > nit: your S-o-b chain doesn't make sense (I would expect you at the end > since you're sending it and showing as the Author). Is it Co-developed-by? > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by Yes, Co-developed-by.  Will adjust. > >> [...] >> + >> + max_buf = SZ_4M; >> + bufp = dma_alloc_coherent(dev, >> + max_buf, >> + &boot_dma_addr, GFP_KERNEL); >> + if (!bufp) { >> + dev_err(dev, "Error allocating 0x%zx\n", max_buf); >> + ret = -ENOMEM; >> + goto err_buf_out; >> + } >> + >> + bcm_vk_buf_notify(vk, bufp, boot_dma_addr, max_buf); >> + } else { >> + dev_err(dev, "Error invalid image type 0x%x\n", load_type); >> + ret = -EINVAL; >> + goto err_buf_out; >> + } >> + >> + ret = request_partial_firmware_into_buf(&fw, filename, dev, >> + bufp, max_buf, 0); > Unless I don't understand what's happening here, this needs to be > reordered if you're going to keep Mimi happy and disallow the device > being able to see the firmware before it has been verified. (i.e. please > load the firmware before mapping DMA across the buffer.) I don't understand your concern here.  We request partial firmware into a buffer that we allocated. After loading it we signal the card the firmware has been loaded into that memory region. The card then pulls the data into its internal memory.  And, authenticates it. Even if the card randomly read and writes to that buffer it shouldn't matter to the linux kernel security subsystem. It passed the security check already when placed in the buffer. If there is a concern could we add an "nosecurity" request_partial_firmware_into_buf instead as there is no need for any security on this particular request?