From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::243; helo=mail-wm0-x243.google.com; envelope-from=roman.bacik@broadcom.com; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2AC6A20957B06 for ; Wed, 11 Jul 2018 08:45:20 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id s14-v6so3092331wmc.1 for ; Wed, 11 Jul 2018 08:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=efkzZvpDIekJ4L+L1d+TjG94XOt21q0qIo6pWHLro3E=; b=gex/FylUhGNWAWKxc9VYJ4tsVag7NofxTRuDqL0dyvY2qWKpLwNr1ZxCxaaWfEDkAf lCU62ZtOwrV3hwA+3Av2DScITSu3exTEaxCcSX/hXFPXlc/UKPjr/6+fiTa3zOu0nLch aX8ekzuVzpRqsBjxGOWV9KNhGL9sIYxXL3HVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=efkzZvpDIekJ4L+L1d+TjG94XOt21q0qIo6pWHLro3E=; b=Xk7S8OKMcDLj9M1aX2YR5KIxdD9oLXfzVHE31W3zc4kPYR/2RIWRPlwzE1Kt8POMPS LDeOMVrVgMCEhmwvz/XmGuWnCqunGXsgoMRV7Y1R8gO+DSGg0vSCTSUri68kgXFe3h3A T7SOQws6pN+8J2u6AmqEVJKwMA+XFuSiTt+lcm7NIbghQj9P1aBOZ/fcXCu+j5Y8eegz rM19H/Hydax6AZ0WysH+HMYSYwxBgfrLbJ2jJptfz607rxg6iNSEH8m1YCbqW6QEbgf0 ea7P5QxBSy1zsIIizPRqj6Bc933u7/xWsN49nxmsKoC5VvHNAH0Gj6xqlcq3/n0GQruo iDCA== X-Gm-Message-State: APt69E18lnoY5D+rDf9p9onv7JxMiwQ7s9uU2OytpY6to8+ImPDsIN0F D1aW8fZxlxrg/YAs5YeHG9hoDicf3HAVkQISUNdaaQ== X-Google-Smtp-Source: AAOMgpdUo5oWLY8UBmhKnqMr/Zv9OFVNfLBY6wzpLoAjgHaYYdwVjzhR5rxjyxuJBuk/vzLilcc7QpUqP3OU4Py9AVY= X-Received: by 2002:a1c:ee9a:: with SMTP id j26-v6mr16582443wmi.116.1531323918068; Wed, 11 Jul 2018 08:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:f505:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 08:44:37 -0700 (PDT) In-Reply-To: <5bca3f43-7c23-dca6-03cd-2d647d8fe253@redhat.com> References: <20180710225105.28443-1-roman.bacik@broadcom.com> <5bca3f43-7c23-dca6-03cd-2d647d8fe253@redhat.com> From: Roman Bacik Date: Wed, 11 Jul 2018 08:44:37 -0700 Message-ID: To: Laszlo Ersek Cc: Roman Bacik , edk2-devel@lists.01.org, Vladimir Olovyannikov , "Jordan Justen (Intel address)" , "Gao, Liming" , Jiewen Yao , Michael Kinney , Chao Zhang X-Content-Filtered-By: Mailman/MimeDel 2.1.27 Subject: Re: [PATCH v2] SecurityPkg: Fix assert when setting key from eMMC/SD/USB X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 15:45:20 -0000 Content-Type: text/plain; charset="UTF-8" Hi Laszlo, Thank you very much for your review and help. I would prefer the option 2b. Thanks, Roman On Wed, Jul 11, 2018 at 5:05 AM, Laszlo Ersek wrote: > Hi Roman, > > On 07/11/18 00:51, rbacik@gmail.com wrote: > > From: Roman Bacik > > > > When secure boot is enabled, if one loads keys from a FAT formatted > > eMMC/SD/USB when trying to provision PK/KEK/DB keys via the menu, > > an assert in StrLen() occurs. > > This is because the filename starts on odd address, which is not a uint16 > > aligned boundary: https://bugzilla.tianocore.org/show_bug.cgi?id=1003 > > > > Cc: Chao Zhang > > Cc: Jiewen Yao > > Cc: Laszlo Ersek > > Cc: Vladimir Olovyannikov > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Roman Bacik > > --- > > SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigFileExplorer.c > | 13 +++++++++++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > Thank you for sending a well-formed patch. > > I notice that you sent this email from , which is not > the same as the Signed-off-by line. I realize you posted from > for technical reasons, and it should be no problem. > > However, I *think* in such cases we usually request the following: > > - Using your broadcom.com email address, please respond to this patch > (not my present email, but your original git posting), keeping full > context, and just repeat your Signed-off-by line (referencing the > broadcom address). > > I'm CC'ing Jordan and Ard for confirmation -- I believe this is what > we've done in the past, in cases when submitters had to post their work > from private addresses due to company email issues. > > Technical comments below: > > > diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigFileExplorer.c > b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/ > SecureBootConfigFileExplorer.c > > index 1b6f88804275..19b13a5569a6 100644 > > --- a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/ > SecureBootConfigFileExplorer.c > > +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/ > SecureBootConfigFileExplorer.c > > @@ -123,6 +123,8 @@ OpenFileByDevicePath( > > EFI_FILE_PROTOCOL *Handle1; > > EFI_FILE_PROTOCOL *Handle2; > > EFI_HANDLE DeviceHandle; > > + CHAR16 *PathName; > > + UINTN PathLength; > > > > if ((FilePath == NULL || FileHandle == NULL)) { > > return EFI_INVALID_PARAMETER; > > @@ -173,6 +175,11 @@ OpenFileByDevicePath( > > // > > Handle2 = Handle1; > > Handle1 = NULL; > > + PathLength = DevicePathNodeLength(*FilePath) - > sizeof(EFI_DEVICE_PATH_PROTOCOL); > > + PathName = AllocateCopyPool(PathLength, ((FILEPATH_DEVICE_PATH*)* > FilePath)->PathName); > > (1) On both lines above, space characters are missing after: > DevicePathNodeLength, sizeof, and AllocateCopyPool. (Edk2 coding style.) > I think we can fix this up for you when we push the patch. (I'm willing > to help with that, but we need SecurityPkg maintainer review first.) > > > > + if (PathName == NULL) { > > + return EFI_OUT_OF_RESOURCES; > > + } > > (2) I have now reviewed the original state of the function more > carefully, and, while the above "return" branch introduces a leak > *path*, it does not introduce a leak that doesn't already exist! > > In fact, the original function has multiple issues: > > - If the OpenVolume() call fails, "FileHandle" is set to NULL. That's > useless; the intent is obviously to set (*FileHandle) to NULL. > > - At the top of the "while" loop body, "Handle1" stands for an open > EFI_FILE_PROTOCOL. If the device path type check at the top of the loop > body returns EFI_INVALID_PARAMETER, then it (a) performs the same > useless assignment to "FileHandle" as described above, and (b) fails to > close "Handle1". This is why I say that the above EFI_OUT_OF_RESOURCES > branch introduces no new leak, just a new path to the existent leak. > > - The OpenFileByDevicePath() function is duplicated in the following > modules: "NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c", and > "MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskFileExplorer.c". With the > implication that the alignment issue you found affects all three drivers! > > > Roman, I realize this could be more than what you signed up for; so > please pick one: > > (2a) you could submit a patch series: > > * Write a patch that sets (*FilePath) to NULL right after the > (FileHandle==NULL) check, in preparation for failure, and removes all > the bogus FileHandle=NULL assignments. > > * Write another patch that plugs the leak when the device path type > check fails -- introduce a "CloseHandle1" label at the end of the > function, and jump to it when the devpath type check fails, so that we > close "Handle1". This patch should also invert the meanings of Handle2 > and Handle1 -- the reassignment to Handle1 should only occur *after* we > successfully open Handle2. "Handle1" should *always* remain suitable for > closing through the "CloseHandle1" error path. > > * Include your current patch, for fixing the alignment issue. > > * Write another patch that moves the OpenFileByDevicePath() function to > UefiLib in MdePkg -- under the name EfiOpenFileByDevicePath() -- from > SecureBootConfigDxe. > > * write two more patches, namely for TlsAuthConfigDxe and RamDiskDxe, in > order to consume EfiOpenFileByDevicePath() from UefiLib. Both of those > modules already depend on UefiLib. > > (2b) Alternatively: > > * we can report a new TianoCore BZ about the issues I list above, > > * we can commit this patch of yours as-is, just additionally reference > the *new* BZ in the commit message, as "further known issues", > > * I can work on the rest of the issues. > > > If you pick (2b), then I can > - file the new BZ, > - update the commit message for you, > - update the patch for you, as described in (1), > - ACK this patch (as updated above), > - push the patch (if SecurityPkg maintainers agree), > - take on the new BZ as well. > > Thanks! > Laszlo > > > > > // > > // Try to test opening an existing file > > @@ -180,7 +187,7 @@ OpenFileByDevicePath( > > Status = Handle2->Open ( > > Handle2, > > &Handle1, > > - ((FILEPATH_DEVICE_PATH*)*FilePath)->PathName, > > + PathName, > > OpenMode &~EFI_FILE_MODE_CREATE, > > 0 > > ); > > @@ -192,7 +199,7 @@ OpenFileByDevicePath( > > Status = Handle2->Open ( > > Handle2, > > &Handle1, > > - ((FILEPATH_DEVICE_PATH*)* > FilePath)->PathName, > > + PathName, > > OpenMode, > > Attributes > > ); > > @@ -202,6 +209,8 @@ OpenFileByDevicePath( > > // > > Handle2->Close (Handle2); > > > > + FreePool (PathName); > > + > > if (EFI_ERROR(Status)) { > > return (Status); > > } > > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >