From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
"Zhang, Chao B" <chao.b.zhang@intel.com>,
"Dong, Eric" <eric.dong@intel.com>,
"Carsey, Jaben" <jaben.carsey@intel.com>,
"Wu, Jiaxin" <jiaxin.wu@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
Roman Bacik <roman.bacik@broadcom.com>,
"Ni, Ruiyu" <ruiyu.ni@intel.com>,
"Fu, Siyuan" <siyuan.fu@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [PATCH 1/6] MdePkg/UefiLib: introduce EfiOpenFileByDevicePath()
Date: Thu, 19 Jul 2018 13:03:10 +0000 [thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503ACB6C6D@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <14d68d9a-5780-1523-d03f-611562c15bc9@redhat.com>
Cool. Thanks!
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, July 19, 2018 6:47 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Zhang, Chao B
> <chao.b.zhang@intel.com>; Dong, Eric <eric.dong@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> Roman Bacik <roman.bacik@broadcom.com>; Ni, Ruiyu <ruiyu.ni@intel.com>;
> Fu, Siyuan <siyuan.fu@intel.com>; Zeng, Star <star.zeng@intel.com>
> Subject: Re: [PATCH 1/6] MdePkg/UefiLib: introduce EfiOpenFileByDevicePath()
>
> On 07/19/18 01:10, Yao, Jiewen wrote:
> > Thanks Laszlo.
> >
> > Would you please add one line comment on the FilePath, to describe if the
> FilePath is internal input or external input? As such the API consumer can
> know if caller’s responsibility to verify it or callee’s responsibility.
>
> Good point. The caller is responsible for ensuring the well-formedness
> of the device path pointed-to by (*FilePath). The function uses
> DevicePathLib APIs such as NextDevicePathNode(), and if e.g. some device
> path node headers are invalid (containing bogus lengths, for example),
> then the function won't work as expected.
>
> I'll add such a comment.
>
> > For example, if the caller gets path from a read write variable, and input it
> directly, the this API need validate before use.
> > If the caller already does the verification, then this API can use it directly.
>
> Right.
>
> (A separate question would be if edk2 offers facilities for verifying
> the well-formedness of any given device path -- it looks like a complex
> task, to implement everywhere.)
>
> In this series I'd just like to extract the duplicated code to a common
> location, and fix its bugs. I didn't try to change the interface
> contract (just to document it more precisely). If we'd like to "armor"
> this function against maliciously formatted device paths, IMO that
> should be done separately.
>
> So I agree that the comment you suggest should be added.
>
> > Sanity check is just for the format, not the content.
> > The question I have is: Where should the sanity check be?
>
> At the moment: in the caller.
>
> Thanks!
> Laszlo
>
> >
> > thank you!
> > Yao, Jiewen
> >
> >
> >> 在 2018年7月19日,上午4:50,Laszlo Ersek <lersek@redhat.com> 写
> 道:
> >>
> >> The EfiOpenFileByDevicePath() function centralizes functionality from
> >>
> >> - MdeModulePkg/Universal/Disk/RamDiskDxe
> >> - NetworkPkg/TlsAuthConfigDxe
> >> - SecurityPkg/VariableAuthenticated/SecureBootConfigDxe
> >> - ShellPkg/Library/UefiShellLib
> >>
> >> unifying the implementation and fixing various bugs.
> >>
> >> Cc: Chao Zhang <chao.b.zhang@intel.com>
> >> Cc: Eric Dong <eric.dong@intel.com>
> >> Cc: Jaben Carsey <jaben.carsey@intel.com>
> >> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> >> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >> Cc: Liming Gao <liming.gao@intel.com>
> >> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >> Cc: Roman Bacik <roman.bacik@broadcom.com>
> >> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> >> Cc: Siyuan Fu <siyuan.fu@intel.com>
> >> Cc: Star Zeng <star.zeng@intel.com>
> >> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1008
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >> MdePkg/Library/UefiLib/UefiLib.inf | 1 +
> >> MdePkg/Include/Library/UefiLib.h | 86 ++++++++
> >> MdePkg/Library/UefiLib/UefiLib.c | 226 ++++++++++++++++++++
> >> 3 files changed, 313 insertions(+)
> >>
> >> diff --git a/MdePkg/Library/UefiLib/UefiLib.inf
> b/MdePkg/Library/UefiLib/UefiLib.inf
> >> index f69f0a43b576..a6c739ef3d6d 100644
> >> --- a/MdePkg/Library/UefiLib/UefiLib.inf
> >> +++ b/MdePkg/Library/UefiLib/UefiLib.inf
> >> @@ -68,6 +68,7 @@ [Protocols]
> >> gEfiSimpleTextOutProtocolGuid ##
> SOMETIMES_CONSUMES
> >> gEfiGraphicsOutputProtocolGuid ##
> SOMETIMES_CONSUMES
> >> gEfiHiiFontProtocolGuid ##
> SOMETIMES_CONSUMES
> >> + gEfiSimpleFileSystemProtocolGuid ##
> SOMETIMES_CONSUMES
> >> gEfiUgaDrawProtocolGuid |
> gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport ##
> SOMETIMES_CONSUMES # Consumes if gEfiGraphicsOutputProtocolGuid
> uninstalled
> >> gEfiComponentNameProtocolGuid | NOT
> gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable ##
> SOMETIMES_PRODUCES # User chooses to produce it
> >> gEfiComponentName2ProtocolGuid | NOT
> gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable ##
> SOMETIMES_PRODUCES # User chooses to produce it
> >> diff --git a/MdePkg/Include/Library/UefiLib.h
> b/MdePkg/Include/Library/UefiLib.h
> >> index 7c6fde620c74..2468bf2aee80 100644
> >> --- a/MdePkg/Include/Library/UefiLib.h
> >> +++ b/MdePkg/Include/Library/UefiLib.h
> >> @@ -33,6 +33,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> >> #include <Protocol/DriverDiagnostics.h>
> >> #include <Protocol/DriverDiagnostics2.h>
> >> #include <Protocol/GraphicsOutput.h>
> >> +#include <Protocol/DevicePath.h>
> >> +#include <Protocol/SimpleFileSystem.h>
> >>
> >> #include <Library/BaseLib.h>
> >>
> >> @@ -1520,4 +1522,88 @@ EfiLocateProtocolBuffer (
> >> OUT UINTN *NoProtocols,
> >> OUT VOID ***Buffer
> >> );
> >> +
> >> +/**
> >> + Open or create a file or directory, possibly creating the chain of
> >> + directories leading up to the directory.
> >> +
> >> + EfiOpenFileByDevicePath() first locates
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on
> >> + FilePath, and opens the root directory of that filesystem with
> >> + EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
> >> +
> >> + On the remaining device path, the longest initial sequence of
> >> + FILEPATH_DEVICE_PATH nodes is node-wise traversed with
> >> + EFI_FILE_PROTOCOL.Open(). For the pathname fragment specified by
> each
> >> + traversed FILEPATH_DEVICE_PATH node, EfiOpenFileByDevicePath() first
> masks
> >> + EFI_FILE_MODE_CREATE out of OpenMode, and passes 0 for Attributes.
> If
> >> + EFI_FILE_PROTOCOL.Open() fails, and OpenMode includes
> EFI_FILE_MODE_CREATE,
> >> + then the operation is retried with the caller's OpenMode and Attributes
> >> + unmodified.
> >> +
> >> + (As a consequence, if OpenMode includes EFI_FILE_MODE_CREATE, and
> Attributes
> >> + includes EFI_FILE_DIRECTORY, and each FILEPATH_DEVICE_PATH specifies
> a single
> >> + pathname component, then EfiOpenFileByDevicePath() ensures that the
> specified
> >> + series of subdirectories exist on return.)
> >> +
> >> + The EFI_FILE_PROTOCOL identified by the last FILEPATH_DEVICE_PATH
> node is
> >> + output to the caller; intermediate EFI_FILE_PROTOCOL instances are
> closed. If
> >> + there are no FILEPATH_DEVICE_PATH nodes past the node that identifies
> the
> >> + filesystem, then the EFI_FILE_PROTOCOL of the root directory of the
> >> + filesystem is output to the caller. If a device path node that is different
> >> + from FILEPATH_DEVICE_PATH is encountered relative to the filesystem,
> the
> >> + traversal is stopped with an error, and a NULL EFI_FILE_PROTOCOL is
> output.
> >> +
> >> + @param[in,out] FilePath On input, the device path to the file or
> directory
> >> + to open or create. On output, FilePath
> points one
> >> + past the last node in the original device
> path that
> >> + has been successfully processed. FilePath is
> set on
> >> + output even if EfiOpenFileByDevicePath()
> returns an
> >> + error.
> >> +
> >> + @param[out] File On error, File is set to NULL. On success, File
> is
> >> + set to the EFI_FILE_PROTOCOL of the root
> directory
> >> + of the filesystem, if there are no
> >> + FILEPATH_DEVICE_PATH nodes in FilePath;
> otherwise,
> >> + File is set to the EFI_FILE_PROTOCOL
> identified by
> >> + the last node in FilePath.
> >> +
> >> + @param[in] OpenMode The OpenMode parameter to pass to
> >> + EFI_FILE_PROTOCOL.Open(). For each
> >> + FILEPATH_DEVICE_PATH node in FilePath,
> >> + EfiOpenFileByDevicePath() first opens the
> specified
> >> + pathname fragment with
> EFI_FILE_MODE_CREATE masked
> >> + out of OpenMode and with Attributes set
> to 0, and
> >> + only retries the operation with
> EFI_FILE_MODE_CREATE
> >> + unmasked and Attributes propagated if the
> first open
> >> + attempt fails.
> >> +
> >> + @param[in] Attributes The Attributes parameter to pass to
> >> + EFI_FILE_PROTOCOL.Open(), when
> EFI_FILE_MODE_CREATE
> >> + is propagated unmasked in OpenMode.
> >> +
> >> + @retval EFI_SUCCESS The file or directory has been
> opened or
> >> + created.
> >> +
> >> + @retval EFI_INVALID_PARAMETER FilePath is NULL; or File is NULL; or
> FilePath
> >> + contains a device path node, past
> the node
> >> + that identifies
> >> +
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, that is not a
> >> + FILEPATH_DEVICE_PATH node.
> >> +
> >> + @retval EFI_OUT_OF_RESOURCES Memory allocation failed.
> >> +
> >> + @return Error codes propagated from the
> >> + LocateDevicePath() and
> OpenProtocol() boot
> >> + services, and from the
> >> +
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
> >> + and EFI_FILE_PROTOCOL.Open()
> member functions.
> >> +**/
> >> +EFI_STATUS
> >> +EFIAPI
> >> +EfiOpenFileByDevicePath (
> >> + IN OUT EFI_DEVICE_PATH_PROTOCOL **FilePath,
> >> + OUT EFI_FILE_PROTOCOL **File,
> >> + IN UINT64 OpenMode,
> >> + IN UINT64 Attributes
> >> + );
> >> #endif
> >> diff --git a/MdePkg/Library/UefiLib/UefiLib.c
> b/MdePkg/Library/UefiLib/UefiLib.c
> >> index 828a54ce7a97..d3e290178cd9 100644
> >> --- a/MdePkg/Library/UefiLib/UefiLib.c
> >> +++ b/MdePkg/Library/UefiLib/UefiLib.c
> >> @@ -1719,3 +1719,229 @@ EfiLocateProtocolBuffer (
> >>
> >> return EFI_SUCCESS;
> >> }
> >> +
> >> +/**
> >> + Open or create a file or directory, possibly creating the chain of
> >> + directories leading up to the directory.
> >> +
> >> + EfiOpenFileByDevicePath() first locates
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on
> >> + FilePath, and opens the root directory of that filesystem with
> >> + EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
> >> +
> >> + On the remaining device path, the longest initial sequence of
> >> + FILEPATH_DEVICE_PATH nodes is node-wise traversed with
> >> + EFI_FILE_PROTOCOL.Open(). For the pathname fragment specified by
> each
> >> + traversed FILEPATH_DEVICE_PATH node, EfiOpenFileByDevicePath() first
> masks
> >> + EFI_FILE_MODE_CREATE out of OpenMode, and passes 0 for Attributes.
> If
> >> + EFI_FILE_PROTOCOL.Open() fails, and OpenMode includes
> EFI_FILE_MODE_CREATE,
> >> + then the operation is retried with the caller's OpenMode and Attributes
> >> + unmodified.
> >> +
> >> + (As a consequence, if OpenMode includes EFI_FILE_MODE_CREATE, and
> Attributes
> >> + includes EFI_FILE_DIRECTORY, and each FILEPATH_DEVICE_PATH specifies
> a single
> >> + pathname component, then EfiOpenFileByDevicePath() ensures that the
> specified
> >> + series of subdirectories exist on return.)
> >> +
> >> + The EFI_FILE_PROTOCOL identified by the last FILEPATH_DEVICE_PATH
> node is
> >> + output to the caller; intermediate EFI_FILE_PROTOCOL instances are
> closed. If
> >> + there are no FILEPATH_DEVICE_PATH nodes past the node that identifies
> the
> >> + filesystem, then the EFI_FILE_PROTOCOL of the root directory of the
> >> + filesystem is output to the caller. If a device path node that is different
> >> + from FILEPATH_DEVICE_PATH is encountered relative to the filesystem,
> the
> >> + traversal is stopped with an error, and a NULL EFI_FILE_PROTOCOL is
> output.
> >> +
> >> + @param[in,out] FilePath On input, the device path to the file or
> directory
> >> + to open or create. On output, FilePath
> points one
> >> + past the last node in the original device
> path that
> >> + has been successfully processed. FilePath is
> set on
> >> + output even if EfiOpenFileByDevicePath()
> returns an
> >> + error.
> >> +
> >> + @param[out] File On error, File is set to NULL. On success, File
> is
> >> + set to the EFI_FILE_PROTOCOL of the root
> directory
> >> + of the filesystem, if there are no
> >> + FILEPATH_DEVICE_PATH nodes in FilePath;
> otherwise,
> >> + File is set to the EFI_FILE_PROTOCOL
> identified by
> >> + the last node in FilePath.
> >> +
> >> + @param[in] OpenMode The OpenMode parameter to pass to
> >> + EFI_FILE_PROTOCOL.Open(). For each
> >> + FILEPATH_DEVICE_PATH node in FilePath,
> >> + EfiOpenFileByDevicePath() first opens the
> specified
> >> + pathname fragment with
> EFI_FILE_MODE_CREATE masked
> >> + out of OpenMode and with Attributes set
> to 0, and
> >> + only retries the operation with
> EFI_FILE_MODE_CREATE
> >> + unmasked and Attributes propagated if the
> first open
> >> + attempt fails.
> >> +
> >> + @param[in] Attributes The Attributes parameter to pass to
> >> + EFI_FILE_PROTOCOL.Open(), when
> EFI_FILE_MODE_CREATE
> >> + is propagated unmasked in OpenMode.
> >> +
> >> + @retval EFI_SUCCESS The file or directory has been
> opened or
> >> + created.
> >> +
> >> + @retval EFI_INVALID_PARAMETER FilePath is NULL; or File is NULL; or
> FilePath
> >> + contains a device path node, past
> the node
> >> + that identifies
> >> +
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, that is not a
> >> + FILEPATH_DEVICE_PATH node.
> >> +
> >> + @retval EFI_OUT_OF_RESOURCES Memory allocation failed.
> >> +
> >> + @return Error codes propagated from the
> >> + LocateDevicePath() and
> OpenProtocol() boot
> >> + services, and from the
> >> +
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
> >> + and EFI_FILE_PROTOCOL.Open()
> member functions.
> >> +**/
> >> +EFI_STATUS
> >> +EFIAPI
> >> +EfiOpenFileByDevicePath (
> >> + IN OUT EFI_DEVICE_PATH_PROTOCOL **FilePath,
> >> + OUT EFI_FILE_PROTOCOL **File,
> >> + IN UINT64 OpenMode,
> >> + IN UINT64 Attributes
> >> + )
> >> +{
> >> + EFI_STATUS Status;
> >> + EFI_HANDLE FileSystemHandle;
> >> + EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *FileSystem;
> >> + EFI_FILE_PROTOCOL *LastFile;
> >> +
> >> + if (File == NULL) {
> >> + return EFI_INVALID_PARAMETER;
> >> + }
> >> + *File = NULL;
> >> +
> >> + if (FilePath == NULL) {
> >> + return EFI_INVALID_PARAMETER;
> >> + }
> >> +
> >> + //
> >> + // Look up the filesystem.
> >> + //
> >> + Status = gBS->LocateDevicePath (
> >> + &gEfiSimpleFileSystemProtocolGuid,
> >> + FilePath,
> >> + &FileSystemHandle
> >> + );
> >> + if (EFI_ERROR (Status)) {
> >> + return Status;
> >> + }
> >> + Status = gBS->OpenProtocol (
> >> + FileSystemHandle,
> >> + &gEfiSimpleFileSystemProtocolGuid,
> >> + (VOID **)&FileSystem,
> >> + gImageHandle,
> >> + NULL,
> >> + EFI_OPEN_PROTOCOL_GET_PROTOCOL
> >> + );
> >> + if (EFI_ERROR (Status)) {
> >> + return Status;
> >> + }
> >> +
> >> + //
> >> + // Open the root directory of the filesystem. After this operation
> succeeds,
> >> + // we have to release LastFile on error.
> >> + //
> >> + Status = FileSystem->OpenVolume (FileSystem, &LastFile);
> >> + if (EFI_ERROR (Status)) {
> >> + return Status;
> >> + }
> >> +
> >> + //
> >> + // Traverse the device path nodes relative to the filesystem.
> >> + //
> >> + while (!IsDevicePathEnd (*FilePath)) {
> >> + //
> >> + // Keep local variables that relate to the current device path node
> tightly
> >> + // scoped.
> >> + //
> >> + FILEPATH_DEVICE_PATH *FilePathNode;
> >> + CHAR16 *AlignedPathName;
> >> + CHAR16 *PathName;
> >> + EFI_FILE_PROTOCOL *NextFile;
> >> +
> >> + if (DevicePathType (*FilePath) != MEDIA_DEVICE_PATH ||
> >> + DevicePathSubType (*FilePath) != MEDIA_FILEPATH_DP) {
> >> + Status = EFI_INVALID_PARAMETER;
> >> + goto CloseLastFile;
> >> + }
> >> + FilePathNode = (FILEPATH_DEVICE_PATH *)*FilePath;
> >> +
> >> + //
> >> + // FilePathNode->PathName may be unaligned, and the UEFI
> specification
> >> + // requires pointers that are passed to protocol member functions to
> be
> >> + // aligned. Create an aligned copy of the pathname if necessary.
> >> + //
> >> + if ((UINTN)FilePathNode->PathName % sizeof
> *FilePathNode->PathName == 0) {
> >> + AlignedPathName = NULL;
> >> + PathName = FilePathNode->PathName;
> >> + } else {
> >> + AlignedPathName = AllocateCopyPool (
> >> + (DevicePathNodeLength (FilePathNode) -
> >> + SIZE_OF_FILEPATH_DEVICE_PATH),
> >> + FilePathNode->PathName
> >> + );
> >> + if (AlignedPathName == NULL) {
> >> + Status = EFI_OUT_OF_RESOURCES;
> >> + goto CloseLastFile;
> >> + }
> >> + PathName = AlignedPathName;
> >> + }
> >> +
> >> + //
> >> + // Open the next pathname fragment with EFI_FILE_MODE_CREATE
> masked out and
> >> + // with Attributes set to 0.
> >> + //
> >> + Status = LastFile->Open (
> >> + LastFile,
> >> + &NextFile,
> >> + PathName,
> >> + OpenMode &
> ~(UINT64)EFI_FILE_MODE_CREATE,
> >> + 0
> >> + );
> >> +
> >> + //
> >> + // Retry with EFI_FILE_MODE_CREATE and the original Attributes if the
> first
> >> + // attempt failed, and the caller specified EFI_FILE_MODE_CREATE.
> >> + //
> >> + if (EFI_ERROR (Status) && (OpenMode & EFI_FILE_MODE_CREATE) != 0)
> {
> >> + Status = LastFile->Open (
> >> + LastFile,
> >> + &NextFile,
> >> + PathName,
> >> + OpenMode,
> >> + Attributes
> >> + );
> >> + }
> >> +
> >> + //
> >> + // Release any AlignedPathName on both error and success paths;
> PathName is
> >> + // no longer needed.
> >> + //
> >> + if (AlignedPathName != NULL) {
> >> + FreePool (AlignedPathName);
> >> + }
> >> + if (EFI_ERROR (Status)) {
> >> + goto CloseLastFile;
> >> + }
> >> +
> >> + //
> >> + // Advance to the next device path node.
> >> + //
> >> + LastFile->Close (LastFile);
> >> + LastFile = NextFile;
> >> + *FilePath = NextDevicePathNode (FilePathNode);
> >> + }
> >> +
> >> + *File = LastFile;
> >> + return EFI_SUCCESS;
> >> +
> >> +CloseLastFile:
> >> + LastFile->Close (LastFile);
> >> +
> >> + ASSERT (EFI_ERROR (Status));
> >> + return Status;
> >> +}
> >> --
> >> 2.14.1.3.gb7cf6e02401b
> >>
> >>
next prev parent reply other threads:[~2018-07-19 13:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 20:50 [PATCH 0/6] UefiLib: centralize OpenFileByDevicePath() and fix its bugs Laszlo Ersek
2018-07-18 20:50 ` [PATCH 1/6] MdePkg/UefiLib: introduce EfiOpenFileByDevicePath() Laszlo Ersek
2018-07-18 23:10 ` Yao, Jiewen
2018-07-19 10:47 ` Laszlo Ersek
2018-07-19 13:03 ` Yao, Jiewen [this message]
2018-07-24 17:20 ` Laszlo Ersek
2018-07-27 9:15 ` Ni, Ruiyu
2018-07-27 9:28 ` Ni, Ruiyu
2018-07-27 12:06 ` Laszlo Ersek
2018-07-30 1:54 ` Ni, Ruiyu
2018-07-30 14:13 ` Laszlo Ersek
2018-08-02 4:06 ` Gao, Liming
2018-08-02 14:45 ` Laszlo Ersek
2018-07-18 20:50 ` [PATCH 2/6] MdeModulePkg/RamDiskDxe: replace OpenFileByDevicePath() with UefiLib API Laszlo Ersek
2018-07-19 10:36 ` Zeng, Star
2018-07-19 13:20 ` Laszlo Ersek
2018-07-20 10:22 ` Zeng, Star
2018-07-18 20:50 ` [PATCH 3/6] NetworkPkg/TlsAuthConfigDxe: " Laszlo Ersek
2018-07-24 17:20 ` Laszlo Ersek
2018-07-25 0:30 ` Wu, Jiaxin
2018-07-18 20:50 ` [PATCH 4/6] SecurityPkg/SecureBootConfigDxe: " Laszlo Ersek
2018-07-24 5:09 ` Zhang, Chao B
2018-07-18 20:50 ` [PATCH 5/6] ShellPkg/UefiShellLib: drop DeviceHandle param of ShellOpenFileByDevicePath() Laszlo Ersek
2018-07-18 20:50 ` [PATCH 6/6] ShellPkg/UefiShellLib: rebase ShellOpenFileByDevicePath() to UefiLib API Laszlo Ersek
2018-07-18 21:15 ` [PATCH 0/6] UefiLib: centralize OpenFileByDevicePath() and fix its bugs Carsey, Jaben
2018-07-19 0:07 ` Ard Biesheuvel
2018-07-19 10:38 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74D8A39837DF1E4DA445A8C0B3885C503ACB6C6D@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox