From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.23350.1670525103458636389 for ; Thu, 08 Dec 2022 10:45:03 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IDAjKQc/; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) 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 BD49B6201E for ; Thu, 8 Dec 2022 18:45:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30169C433EF for ; Thu, 8 Dec 2022 18:45:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670525101; bh=sq7LxfTTheo2Q9qPZYjzbvR3YT3YrhPn331OaUudLUo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IDAjKQc///BuGaVFXaqOqz02/YQ9JjcVJJpKOgkcje73raja5G363DIstzx8POn3j OeaqftQdTGDSQbb+4qHT5keM9luA5Kty30FjEhgPeLxIdmCJEx2/WzjG4csuX20hpq RY2Clm7X1PdrAx9X+k0u07Ib6WHrWxQpEZp8/jgy7TXnLl+3OvhYs9tqzsOdADEjDf cf38X0luo7JicLgxjUp/PUkVscVU72MixEUbgwW8DJyB+J8F3d0rdj4qs43whNfn6v BZtWIBHubF1W46RmXbVYQFVPlSxqiQvK2n0U5khPgcfpacF2jg99myCC0PfVqbA30d ScaNNIZVCYY5w== Received: by mail-lf1-f49.google.com with SMTP id p36so3360354lfa.12 for ; Thu, 08 Dec 2022 10:45:01 -0800 (PST) X-Gm-Message-State: ANoB5pkNKP6ZzxpYbTSbEavHLRgIt1aLBYn7HvbjLmXCO6CYYhUiahvb qqvUuQItilgBuL5h/BWSGk6flTkjPIylItuUvK4= X-Google-Smtp-Source: AA0mqf78A8TFCeVUwejauiuNTiAVXuGjvJsY9HnJnGrxEOub23Mv9CpIgRSJ+9yiXfnAi4H+lH6v63AMAfk25aLxhsY= X-Received: by 2002:a05:6512:3c89:b0:4a2:bfd2:b218 with SMTP id h9-20020a0565123c8900b004a2bfd2b218mr31587266lfv.228.1670525099215; Thu, 08 Dec 2022 10:44:59 -0800 (PST) MIME-Version: 1.0 References: <20221207161245.2554193-1-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 8 Dec 2022 19:44:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] ShellPkg: Avoid corrupting installed device path protocols To: "Kinney, Michael D" Cc: "devel@edk2.groups.io" , "Ni, Ray" , "Gao, Zhichao" Content-Type: text/plain; charset="UTF-8" On Thu, 8 Dec 2022 at 19:28, Kinney, Michael D wrote: > > Hi Ard, > > From this description, it does not look like it should be modifying the > contents of the device path. Just point to the device path end node that > follows the match found. > > /** > Gets the mapping that most closely matches the device path. > > This function gets the mapping which corresponds to the device path *DevicePath. If > there is no exact match, then the mapping which most closely matches *DevicePath > is returned, and *DevicePath is updated to point to the remaining portion of the > device path. If there is an exact match, the mapping is returned and *DevicePath > points to the end-of-device-path node. > > @param DevicePath On entry, points to a device path pointer. On > exit, updates the pointer to point to the > portion of the device path after the mapping. > > @retval NULL No mapping was found. > @return !=NULL Pointer to NULL-terminated mapping. The buffer > is callee allocated and should be freed by the caller. > **/ > CONST CHAR16 * > EFIAPI > EfiShellGetMapFromDevicePath ( > IN OUT EFI_DEVICE_PATH_PROTOCOL **DevicePath > ); > > I see this API used in many places, and it looks like it would be > destructive to any multi-instance device path. Multi-instance > device paths are typically used for consoles, so we may not have > noticed this destructive behavior with file system mapping paths. > > Did you try removing the call to SetDevicePathEndNode (*DevicePath); ? > No, but that would be a functional change visible to all users of the current API. And note that the calling code already has 'DevicePathCopy' variables, it just doesn't bother using them, so the intent is clearly to pass a copy, not the actual device path.