[edk2-libc Patch 0/1] added support for uuid.py module for uefi environment

[edk2-libc Patch 0/1] added support for uuid.py module for uefi environment

[Jayaprakash, N]

This patch contains the uuid.py updated module with the changes required to 
support it working on uefi environment.

Jayaprakash Nevara (1):
  AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
    UEFI environment

 .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
 1 file changed, 50 insertions(+), 44 deletions(-)

-- 
2.32.0.windows.2

[edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Jayaprakash, N]

 REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899

 This is commit contains the UEFI port of uuid.py module. Made necessary
 changes required to uuid.py module to support UEFI environment.
 Porting of this module to UEFI is required for open source tools such
 as Chipsec to function properly.

 Cc: Rebecca Cran <rebecca@nuviainc.com>
 Cc: Michael D Kinney <michael.d.kinney@intel.com>
 Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
---
 .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
 1 file changed, 50 insertions(+), 44 deletions(-)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
index db8b2ef..84ed0b8 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
+++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
@@ -471,57 +471,61 @@ def _netbios_getnode():
             continue
         return int.from_bytes(bytes, 'big')
 
+
 # Thanks to Thomas Heller for ctypes and for his help with its use here.
 
 # If ctypes is available, use it to find system routines for UUID generation.
 # XXX This makes the module non-thread-safe!
 _uuid_generate_time = _UuidCreate = None
-try:
-    import ctypes, ctypes.util
-    import sys
-
-    # The uuid_generate_* routines are provided by libuuid on at least
-    # Linux and FreeBSD, and provided by libc on Mac OS X.
-    _libnames = ['uuid']
-    if not sys.platform.startswith('win'):
-        _libnames.append('c')
-    for libname in _libnames:
-        try:
-            lib = ctypes.CDLL(ctypes.util.find_library(libname))
-        except Exception:
-            continue
-        if hasattr(lib, 'uuid_generate_time'):
-            _uuid_generate_time = lib.uuid_generate_time
-            break
-    del _libnames
-
-    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
-    # in issue #8621 the function generates the same sequence of values
-    # in the parent process and all children created using fork (unless
-    # those children use exec as well).
-    #
-    # Assume that the uuid_generate functions are broken from 10.5 onward,
-    # the test can be adjusted when a later version is fixed.
-    if sys.platform == 'darwin':
-        if int(os.uname().release.split('.')[0]) >= 9:
-            _uuid_generate_time = None
-
-    # On Windows prior to 2000, UuidCreate gives a UUID containing the
-    # hardware address.  On Windows 2000 and later, UuidCreate makes a
-    # random UUID and UuidCreateSequential gives a UUID containing the
-    # hardware address.  These routines are provided by the RPC runtime.
-    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
-    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
-    # to bear any relationship to the MAC address of any network device
-    # on the box.
+if os.name != 'edk2':
+    # This code is not meant to run on UEFI environment
     try:
-        lib = ctypes.windll.rpcrt4
+        import ctypes, ctypes.util
+        import sys
+    
+        # The uuid_generate_* routines are provided by libuuid on at least
+        # Linux and FreeBSD, and provided by libc on Mac OS X.
+        _libnames = ['uuid']
+        if not sys.platform.startswith('win'):
+            _libnames.append('c')
+        for libname in _libnames:
+            try:
+                lib = ctypes.CDLL(ctypes.util.find_library(libname))
+            except Exception:
+                continue
+            if hasattr(lib, 'uuid_generate_time'):
+                _uuid_generate_time = lib.uuid_generate_time
+                break
+        del _libnames
+    
+        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
+        # in issue #8621 the function generates the same sequence of values
+        # in the parent process and all children created using fork (unless
+        # those children use exec as well).
+        #
+        # Assume that the uuid_generate functions are broken from 10.5 onward,
+        # the test can be adjusted when a later version is fixed.
+        if sys.platform == 'darwin':
+            if int(os.uname().release.split('.')[0]) >= 9:
+                _uuid_generate_time = None
+    
+        # On Windows prior to 2000, UuidCreate gives a UUID containing the
+        # hardware address.  On Windows 2000 and later, UuidCreate makes a
+        # random UUID and UuidCreateSequential gives a UUID containing the
+        # hardware address.  These routines are provided by the RPC runtime.
+        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
+        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
+        # to bear any relationship to the MAC address of any network device
+        # on the box.
+        try:
+            lib = ctypes.windll.rpcrt4
+        except:
+            lib = None
+        _UuidCreate = getattr(lib, 'UuidCreateSequential',
+                              getattr(lib, 'UuidCreate', None))
     except:
-        lib = None
-    _UuidCreate = getattr(lib, 'UuidCreateSequential',
-                          getattr(lib, 'UuidCreate', None))
-except:
-    pass
+        pass
+
 
 def _unixdll_getnode():
     """Get the hardware address on Unix using ctypes."""
@@ -563,6 +567,8 @@ def getnode():
     import sys
     if sys.platform == 'win32':
         getters = _NODE_GETTERS_WIN32
+    elif sys.platform == 'uefi':
+        getters = []
     else:
         getters = _NODE_GETTERS_UNIX
 
-- 
2.32.0.windows.2

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Michael D Kinney]

How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?

Can you add a description of the technique to the BZ and the commit message?

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jayaprakash, N
> Sent: Friday, April 8, 2022 4:52 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
>  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> 
>  This is commit contains the UEFI port of uuid.py module. Made necessary
>  changes required to uuid.py module to support UEFI environment.
>  Porting of this module to UEFI is required for open source tools such
>  as Chipsec to function properly.
> 
>  Cc: Rebecca Cran <rebecca@nuviainc.com>
>  Cc: Michael D Kinney <michael.d.kinney@intel.com>
>  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> ---
>  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
>  1 file changed, 50 insertions(+), 44 deletions(-)
> 
> diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> index db8b2ef..84ed0b8 100644
> --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> @@ -471,57 +471,61 @@ def _netbios_getnode():
>              continue
>          return int.from_bytes(bytes, 'big')
> 
> +
>  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> 
>  # If ctypes is available, use it to find system routines for UUID generation.
>  # XXX This makes the module non-thread-safe!
>  _uuid_generate_time = _UuidCreate = None
> -try:
> -    import ctypes, ctypes.util
> -    import sys
> -
> -    # The uuid_generate_* routines are provided by libuuid on at least
> -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> -    _libnames = ['uuid']
> -    if not sys.platform.startswith('win'):
> -        _libnames.append('c')
> -    for libname in _libnames:
> -        try:
> -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> -        except Exception:
> -            continue
> -        if hasattr(lib, 'uuid_generate_time'):
> -            _uuid_generate_time = lib.uuid_generate_time
> -            break
> -    del _libnames
> -
> -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> -    # in issue #8621 the function generates the same sequence of values
> -    # in the parent process and all children created using fork (unless
> -    # those children use exec as well).
> -    #
> -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> -    # the test can be adjusted when a later version is fixed.
> -    if sys.platform == 'darwin':
> -        if int(os.uname().release.split('.')[0]) >= 9:
> -            _uuid_generate_time = None
> -
> -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> -    # random UUID and UuidCreateSequential gives a UUID containing the
> -    # hardware address.  These routines are provided by the RPC runtime.
> -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> -    # to bear any relationship to the MAC address of any network device
> -    # on the box.
> +if os.name != 'edk2':
> +    # This code is not meant to run on UEFI environment
>      try:
> -        lib = ctypes.windll.rpcrt4
> +        import ctypes, ctypes.util
> +        import sys
> +
> +        # The uuid_generate_* routines are provided by libuuid on at least
> +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> +        _libnames = ['uuid']
> +        if not sys.platform.startswith('win'):
> +            _libnames.append('c')
> +        for libname in _libnames:
> +            try:
> +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> +            except Exception:
> +                continue
> +            if hasattr(lib, 'uuid_generate_time'):
> +                _uuid_generate_time = lib.uuid_generate_time
> +                break
> +        del _libnames
> +
> +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> +        # in issue #8621 the function generates the same sequence of values
> +        # in the parent process and all children created using fork (unless
> +        # those children use exec as well).
> +        #
> +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> +        # the test can be adjusted when a later version is fixed.
> +        if sys.platform == 'darwin':
> +            if int(os.uname().release.split('.')[0]) >= 9:
> +                _uuid_generate_time = None
> +
> +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> +        # random UUID and UuidCreateSequential gives a UUID containing the
> +        # hardware address.  These routines are provided by the RPC runtime.
> +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> +        # to bear any relationship to the MAC address of any network device
> +        # on the box.
> +        try:
> +            lib = ctypes.windll.rpcrt4
> +        except:
> +            lib = None
> +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> +                              getattr(lib, 'UuidCreate', None))
>      except:
> -        lib = None
> -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> -                          getattr(lib, 'UuidCreate', None))
> -except:
> -    pass
> +        pass
> +
> 
>  def _unixdll_getnode():
>      """Get the hardware address on Unix using ctypes."""
> @@ -563,6 +567,8 @@ def getnode():
>      import sys
>      if sys.platform == 'win32':
>          getters = _NODE_GETTERS_WIN32
> +    elif sys.platform == 'uefi':
> +        getters = []
>      else:
>          getters = _NODE_GETTERS_UNIX
> 
> --
> 2.32.0.windows.2
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Jayaprakash, N]

The UUID generation is done through the random number generation & time unix time stamp features available through the built-in python modules 'random' and 'time' respectively.
The random number & time (unix time stamp or epoch) based method of generating the UUID is already there in uuid.py module, with this patch request enabled this path to take effect for UEFI invocation of this module.

There are some OS specific ways to generate the UUID's such as by using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows. 
These will not work for UEFI and hence added appropriate platform check to ensure that this path is not taken for UEFI invocation. 

Besides this there are MAC address based algorithms available in uuid.py module. 
These algorism are based on reading MAC address through various OS supported methods such as ipconfig command processing, NetBIOS calls on Windows, 
using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux, NetBSD and other flavours of Linux.
These are currently not enabled for UEFI invocation of the uuid module. This has been done through platform check added at appropriate place in the uuid.py module code. 

Regards,
JP
-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com> 
Sent: 08 April 2022 21:14
To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?

Can you add a description of the technique to the BZ and the commit message?

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> Jayaprakash, N
> Sent: Friday, April 8, 2022 4:52 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
>  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> 
>  This is commit contains the UEFI port of uuid.py module. Made 
> necessary  changes required to uuid.py module to support UEFI environment.
>  Porting of this module to UEFI is required for open source tools such  
> as Chipsec to function properly.
> 
>  Cc: Rebecca Cran <rebecca@nuviainc.com>
>  Cc: Michael D Kinney <michael.d.kinney@intel.com>
>  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> ---
>  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
>  1 file changed, 50 insertions(+), 44 deletions(-)
> 
> diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py 
> b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> index db8b2ef..84ed0b8 100644
> --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> @@ -471,57 +471,61 @@ def _netbios_getnode():
>              continue
>          return int.from_bytes(bytes, 'big')
> 
> +
>  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> 
>  # If ctypes is available, use it to find system routines for UUID generation.
>  # XXX This makes the module non-thread-safe!
>  _uuid_generate_time = _UuidCreate = None
> -try:
> -    import ctypes, ctypes.util
> -    import sys
> -
> -    # The uuid_generate_* routines are provided by libuuid on at least
> -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> -    _libnames = ['uuid']
> -    if not sys.platform.startswith('win'):
> -        _libnames.append('c')
> -    for libname in _libnames:
> -        try:
> -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> -        except Exception:
> -            continue
> -        if hasattr(lib, 'uuid_generate_time'):
> -            _uuid_generate_time = lib.uuid_generate_time
> -            break
> -    del _libnames
> -
> -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> -    # in issue #8621 the function generates the same sequence of values
> -    # in the parent process and all children created using fork (unless
> -    # those children use exec as well).
> -    #
> -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> -    # the test can be adjusted when a later version is fixed.
> -    if sys.platform == 'darwin':
> -        if int(os.uname().release.split('.')[0]) >= 9:
> -            _uuid_generate_time = None
> -
> -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> -    # random UUID and UuidCreateSequential gives a UUID containing the
> -    # hardware address.  These routines are provided by the RPC runtime.
> -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> -    # to bear any relationship to the MAC address of any network device
> -    # on the box.
> +if os.name != 'edk2':
> +    # This code is not meant to run on UEFI environment
>      try:
> -        lib = ctypes.windll.rpcrt4
> +        import ctypes, ctypes.util
> +        import sys
> +
> +        # The uuid_generate_* routines are provided by libuuid on at least
> +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> +        _libnames = ['uuid']
> +        if not sys.platform.startswith('win'):
> +            _libnames.append('c')
> +        for libname in _libnames:
> +            try:
> +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> +            except Exception:
> +                continue
> +            if hasattr(lib, 'uuid_generate_time'):
> +                _uuid_generate_time = lib.uuid_generate_time
> +                break
> +        del _libnames
> +
> +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> +        # in issue #8621 the function generates the same sequence of values
> +        # in the parent process and all children created using fork (unless
> +        # those children use exec as well).
> +        #
> +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> +        # the test can be adjusted when a later version is fixed.
> +        if sys.platform == 'darwin':
> +            if int(os.uname().release.split('.')[0]) >= 9:
> +                _uuid_generate_time = None
> +
> +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> +        # random UUID and UuidCreateSequential gives a UUID containing the
> +        # hardware address.  These routines are provided by the RPC runtime.
> +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> +        # to bear any relationship to the MAC address of any network device
> +        # on the box.
> +        try:
> +            lib = ctypes.windll.rpcrt4
> +        except:
> +            lib = None
> +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> +                              getattr(lib, 'UuidCreate', None))
>      except:
> -        lib = None
> -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> -                          getattr(lib, 'UuidCreate', None))
> -except:
> -    pass
> +        pass
> +
> 
>  def _unixdll_getnode():
>      """Get the hardware address on Unix using ctypes."""
> @@ -563,6 +567,8 @@ def getnode():
>      import sys
>      if sys.platform == 'win32':
>          getters = _NODE_GETTERS_WIN32
> +    elif sys.platform == 'uefi':
> +        getters = []
>      else:
>          getters = _NODE_GETTERS_UNIX
> 
> --
> 2.32.0.windows.2
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Jayaprakash, N]

+ Aaron

Regards,
JP

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jayaprakash, N
Sent: 08 April 2022 22:12
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

The UUID generation is done through the random number generation & time unix time stamp features available through the built-in python modules 'random' and 'time' respectively.
The random number & time (unix time stamp or epoch) based method of generating the UUID is already there in uuid.py module, with this patch request enabled this path to take effect for UEFI invocation of this module.

There are some OS specific ways to generate the UUID's such as by using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows. 
These will not work for UEFI and hence added appropriate platform check to ensure that this path is not taken for UEFI invocation. 

Besides this there are MAC address based algorithms available in uuid.py module. 
These algorism are based on reading MAC address through various OS supported methods such as ipconfig command processing, NetBIOS calls on Windows, using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux, NetBSD and other flavours of Linux.
These are currently not enabled for UEFI invocation of the uuid module. This has been done through platform check added at appropriate place in the uuid.py module code. 

Regards,
JP
-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: 08 April 2022 21:14
To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?

Can you add a description of the technique to the BZ and the commit message?

Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> Jayaprakash, N
> Sent: Friday, April 8, 2022 4:52 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [edk2-libc Patch 1/1]
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
>  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> 
>  This is commit contains the UEFI port of uuid.py module. Made 
> necessary  changes required to uuid.py module to support UEFI environment.
>  Porting of this module to UEFI is required for open source tools such 
> as Chipsec to function properly.
> 
>  Cc: Rebecca Cran <rebecca@nuviainc.com>
>  Cc: Michael D Kinney <michael.d.kinney@intel.com>
>  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> ---
>  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
>  1 file changed, 50 insertions(+), 44 deletions(-)
> 
> diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> index db8b2ef..84ed0b8 100644
> --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> @@ -471,57 +471,61 @@ def _netbios_getnode():
>              continue
>          return int.from_bytes(bytes, 'big')
> 
> +
>  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> 
>  # If ctypes is available, use it to find system routines for UUID generation.
>  # XXX This makes the module non-thread-safe!
>  _uuid_generate_time = _UuidCreate = None
> -try:
> -    import ctypes, ctypes.util
> -    import sys
> -
> -    # The uuid_generate_* routines are provided by libuuid on at least
> -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> -    _libnames = ['uuid']
> -    if not sys.platform.startswith('win'):
> -        _libnames.append('c')
> -    for libname in _libnames:
> -        try:
> -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> -        except Exception:
> -            continue
> -        if hasattr(lib, 'uuid_generate_time'):
> -            _uuid_generate_time = lib.uuid_generate_time
> -            break
> -    del _libnames
> -
> -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> -    # in issue #8621 the function generates the same sequence of values
> -    # in the parent process and all children created using fork (unless
> -    # those children use exec as well).
> -    #
> -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> -    # the test can be adjusted when a later version is fixed.
> -    if sys.platform == 'darwin':
> -        if int(os.uname().release.split('.')[0]) >= 9:
> -            _uuid_generate_time = None
> -
> -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> -    # random UUID and UuidCreateSequential gives a UUID containing the
> -    # hardware address.  These routines are provided by the RPC runtime.
> -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> -    # to bear any relationship to the MAC address of any network device
> -    # on the box.
> +if os.name != 'edk2':
> +    # This code is not meant to run on UEFI environment
>      try:
> -        lib = ctypes.windll.rpcrt4
> +        import ctypes, ctypes.util
> +        import sys
> +
> +        # The uuid_generate_* routines are provided by libuuid on at least
> +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> +        _libnames = ['uuid']
> +        if not sys.platform.startswith('win'):
> +            _libnames.append('c')
> +        for libname in _libnames:
> +            try:
> +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> +            except Exception:
> +                continue
> +            if hasattr(lib, 'uuid_generate_time'):
> +                _uuid_generate_time = lib.uuid_generate_time
> +                break
> +        del _libnames
> +
> +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> +        # in issue #8621 the function generates the same sequence of values
> +        # in the parent process and all children created using fork (unless
> +        # those children use exec as well).
> +        #
> +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> +        # the test can be adjusted when a later version is fixed.
> +        if sys.platform == 'darwin':
> +            if int(os.uname().release.split('.')[0]) >= 9:
> +                _uuid_generate_time = None
> +
> +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> +        # random UUID and UuidCreateSequential gives a UUID containing the
> +        # hardware address.  These routines are provided by the RPC runtime.
> +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> +        # to bear any relationship to the MAC address of any network device
> +        # on the box.
> +        try:
> +            lib = ctypes.windll.rpcrt4
> +        except:
> +            lib = None
> +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> +                              getattr(lib, 'UuidCreate', None))
>      except:
> -        lib = None
> -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> -                          getattr(lib, 'UuidCreate', None))
> -except:
> -    pass
> +        pass
> +
> 
>  def _unixdll_getnode():
>      """Get the hardware address on Unix using ctypes."""
> @@ -563,6 +567,8 @@ def getnode():
>      import sys
>      if sys.platform == 'win32':
>          getters = _NODE_GETTERS_WIN32
> +    elif sys.platform == 'uefi':
> +        getters = []
>      else:
>          getters = _NODE_GETTERS_UNIX
> 
> --
> 2.32.0.windows.2
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Michael D Kinney]

Thanks JP.

That makes sense.  Bypass all the OS specific services in UEFI environment and generate UUID using time and random number.

Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Mike


> -----Original Message-----
> From: Jayaprakash, N <n.jayaprakash@intel.com>
> Sent: Friday, April 8, 2022 10:19 AM
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
> + Aaron
> 
> Regards,
> JP
> 
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jayaprakash, N
> Sent: 08 April 2022 22:12
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
> The UUID generation is done through the random number generation & time unix time stamp features available through the built-in
> python modules 'random' and 'time' respectively.
> The random number & time (unix time stamp or epoch) based method of generating the UUID is already there in uuid.py module,
> with this patch request enabled this path to take effect for UEFI invocation of this module.
> 
> There are some OS specific ways to generate the UUID's such as by using the libuuid on Linux kind of OS, windll.rpcrt4 library
> on windows.
> These will not work for UEFI and hence added appropriate platform check to ensure that this path is not taken for UEFI
> invocation.
> 
> Besides this there are MAC address based algorithms available in uuid.py module.
> These algorism are based on reading MAC address through various OS supported methods such as ipconfig command processing,
> NetBIOS calls on Windows, using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux,
> NetBSD and other flavours of Linux.
> These are currently not enabled for UEFI invocation of the uuid module. This has been done through platform check added at
> appropriate place in the uuid.py module code.
> 
> Regards,
> JP
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: 08 April 2022 21:14
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
> How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?
> 
> Can you add a description of the technique to the BZ and the commit message?
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > Jayaprakash, N
> > Sent: Friday, April 8, 2022 4:52 AM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
> > UEFI environment
> >
> >  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> >
> >  This is commit contains the UEFI port of uuid.py module. Made
> > necessary  changes required to uuid.py module to support UEFI environment.
> >  Porting of this module to UEFI is required for open source tools such
> > as Chipsec to function properly.
> >
> >  Cc: Rebecca Cran <rebecca@nuviainc.com>
> >  Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> > ---
> >  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
> >  1 file changed, 50 insertions(+), 44 deletions(-)
> >
> > diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > index db8b2ef..84ed0b8 100644
> > --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > @@ -471,57 +471,61 @@ def _netbios_getnode():
> >              continue
> >          return int.from_bytes(bytes, 'big')
> >
> > +
> >  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> >
> >  # If ctypes is available, use it to find system routines for UUID generation.
> >  # XXX This makes the module non-thread-safe!
> >  _uuid_generate_time = _UuidCreate = None
> > -try:
> > -    import ctypes, ctypes.util
> > -    import sys
> > -
> > -    # The uuid_generate_* routines are provided by libuuid on at least
> > -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> > -    _libnames = ['uuid']
> > -    if not sys.platform.startswith('win'):
> > -        _libnames.append('c')
> > -    for libname in _libnames:
> > -        try:
> > -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > -        except Exception:
> > -            continue
> > -        if hasattr(lib, 'uuid_generate_time'):
> > -            _uuid_generate_time = lib.uuid_generate_time
> > -            break
> > -    del _libnames
> > -
> > -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > -    # in issue #8621 the function generates the same sequence of values
> > -    # in the parent process and all children created using fork (unless
> > -    # those children use exec as well).
> > -    #
> > -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> > -    # the test can be adjusted when a later version is fixed.
> > -    if sys.platform == 'darwin':
> > -        if int(os.uname().release.split('.')[0]) >= 9:
> > -            _uuid_generate_time = None
> > -
> > -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > -    # random UUID and UuidCreateSequential gives a UUID containing the
> > -    # hardware address.  These routines are provided by the RPC runtime.
> > -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > -    # to bear any relationship to the MAC address of any network device
> > -    # on the box.
> > +if os.name != 'edk2':
> > +    # This code is not meant to run on UEFI environment
> >      try:
> > -        lib = ctypes.windll.rpcrt4
> > +        import ctypes, ctypes.util
> > +        import sys
> > +
> > +        # The uuid_generate_* routines are provided by libuuid on at least
> > +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> > +        _libnames = ['uuid']
> > +        if not sys.platform.startswith('win'):
> > +            _libnames.append('c')
> > +        for libname in _libnames:
> > +            try:
> > +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > +            except Exception:
> > +                continue
> > +            if hasattr(lib, 'uuid_generate_time'):
> > +                _uuid_generate_time = lib.uuid_generate_time
> > +                break
> > +        del _libnames
> > +
> > +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > +        # in issue #8621 the function generates the same sequence of values
> > +        # in the parent process and all children created using fork (unless
> > +        # those children use exec as well).
> > +        #
> > +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> > +        # the test can be adjusted when a later version is fixed.
> > +        if sys.platform == 'darwin':
> > +            if int(os.uname().release.split('.')[0]) >= 9:
> > +                _uuid_generate_time = None
> > +
> > +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > +        # random UUID and UuidCreateSequential gives a UUID containing the
> > +        # hardware address.  These routines are provided by the RPC runtime.
> > +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > +        # to bear any relationship to the MAC address of any network device
> > +        # on the box.
> > +        try:
> > +            lib = ctypes.windll.rpcrt4
> > +        except:
> > +            lib = None
> > +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > +                              getattr(lib, 'UuidCreate', None))
> >      except:
> > -        lib = None
> > -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > -                          getattr(lib, 'UuidCreate', None))
> > -except:
> > -    pass
> > +        pass
> > +
> >
> >  def _unixdll_getnode():
> >      """Get the hardware address on Unix using ctypes."""
> > @@ -563,6 +567,8 @@ def getnode():
> >      import sys
> >      if sys.platform == 'win32':
> >          getters = _NODE_GETTERS_WIN32
> > +    elif sys.platform == 'uefi':
> > +        getters = []
> >      else:
> >          getters = _NODE_GETTERS_UNIX
> >
> > --
> > 2.32.0.windows.2
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Jayaprakash, N]

Hi Mike,

This patch is yet to be merged. Could you look into this?

Regards,
JP

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com> 
Sent: 08 April 2022 23:30
To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

Thanks JP.

That makes sense.  Bypass all the OS specific services in UEFI environment and generate UUID using time and random number.

Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Mike


> -----Original Message-----
> From: Jayaprakash, N <n.jayaprakash@intel.com>
> Sent: Friday, April 8, 2022 10:19 AM
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; 
> Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> + Aaron
> 
> Regards,
> JP
> 
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> Jayaprakash, N
> Sent: 08 April 2022 22:12
> To: Kinney, Michael D <michael.d.kinney@intel.com>; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> The UUID generation is done through the random number generation & 
> time unix time stamp features available through the built-in python modules 'random' and 'time' respectively.
> The random number & time (unix time stamp or epoch) based method of 
> generating the UUID is already there in uuid.py module, with this patch request enabled this path to take effect for UEFI invocation of this module.
> 
> There are some OS specific ways to generate the UUID's such as by 
> using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows.
> These will not work for UEFI and hence added appropriate platform 
> check to ensure that this path is not taken for UEFI invocation.
> 
> Besides this there are MAC address based algorithms available in uuid.py module.
> These algorism are based on reading MAC address through various OS 
> supported methods such as ipconfig command processing, NetBIOS calls 
> on Windows, using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux, NetBSD and other flavours of Linux.
> These are currently not enabled for UEFI invocation of the uuid 
> module. This has been done through platform check added at appropriate place in the uuid.py module code.
> 
> Regards,
> JP
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: 08 April 2022 21:14
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; 
> Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?
> 
> Can you add a description of the technique to the BZ and the commit message?
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> > Jayaprakash, N
> > Sent: Friday, April 8, 2022 4:52 AM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> > UEFI environment
> >
> >  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> >
> >  This is commit contains the UEFI port of uuid.py module. Made 
> > necessary  changes required to uuid.py module to support UEFI environment.
> >  Porting of this module to UEFI is required for open source tools 
> > such as Chipsec to function properly.
> >
> >  Cc: Rebecca Cran <rebecca@nuviainc.com>
> >  Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> > ---
> >  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
> >  1 file changed, 50 insertions(+), 44 deletions(-)
> >
> > diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > index db8b2ef..84ed0b8 100644
> > --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > @@ -471,57 +471,61 @@ def _netbios_getnode():
> >              continue
> >          return int.from_bytes(bytes, 'big')
> >
> > +
> >  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> >
> >  # If ctypes is available, use it to find system routines for UUID generation.
> >  # XXX This makes the module non-thread-safe!
> >  _uuid_generate_time = _UuidCreate = None
> > -try:
> > -    import ctypes, ctypes.util
> > -    import sys
> > -
> > -    # The uuid_generate_* routines are provided by libuuid on at least
> > -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> > -    _libnames = ['uuid']
> > -    if not sys.platform.startswith('win'):
> > -        _libnames.append('c')
> > -    for libname in _libnames:
> > -        try:
> > -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > -        except Exception:
> > -            continue
> > -        if hasattr(lib, 'uuid_generate_time'):
> > -            _uuid_generate_time = lib.uuid_generate_time
> > -            break
> > -    del _libnames
> > -
> > -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > -    # in issue #8621 the function generates the same sequence of values
> > -    # in the parent process and all children created using fork (unless
> > -    # those children use exec as well).
> > -    #
> > -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> > -    # the test can be adjusted when a later version is fixed.
> > -    if sys.platform == 'darwin':
> > -        if int(os.uname().release.split('.')[0]) >= 9:
> > -            _uuid_generate_time = None
> > -
> > -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > -    # random UUID and UuidCreateSequential gives a UUID containing the
> > -    # hardware address.  These routines are provided by the RPC runtime.
> > -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > -    # to bear any relationship to the MAC address of any network device
> > -    # on the box.
> > +if os.name != 'edk2':
> > +    # This code is not meant to run on UEFI environment
> >      try:
> > -        lib = ctypes.windll.rpcrt4
> > +        import ctypes, ctypes.util
> > +        import sys
> > +
> > +        # The uuid_generate_* routines are provided by libuuid on at least
> > +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> > +        _libnames = ['uuid']
> > +        if not sys.platform.startswith('win'):
> > +            _libnames.append('c')
> > +        for libname in _libnames:
> > +            try:
> > +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > +            except Exception:
> > +                continue
> > +            if hasattr(lib, 'uuid_generate_time'):
> > +                _uuid_generate_time = lib.uuid_generate_time
> > +                break
> > +        del _libnames
> > +
> > +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > +        # in issue #8621 the function generates the same sequence of values
> > +        # in the parent process and all children created using fork (unless
> > +        # those children use exec as well).
> > +        #
> > +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> > +        # the test can be adjusted when a later version is fixed.
> > +        if sys.platform == 'darwin':
> > +            if int(os.uname().release.split('.')[0]) >= 9:
> > +                _uuid_generate_time = None
> > +
> > +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > +        # random UUID and UuidCreateSequential gives a UUID containing the
> > +        # hardware address.  These routines are provided by the RPC runtime.
> > +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > +        # to bear any relationship to the MAC address of any network device
> > +        # on the box.
> > +        try:
> > +            lib = ctypes.windll.rpcrt4
> > +        except:
> > +            lib = None
> > +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > +                              getattr(lib, 'UuidCreate', None))
> >      except:
> > -        lib = None
> > -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > -                          getattr(lib, 'UuidCreate', None))
> > -except:
> > -    pass
> > +        pass
> > +
> >
> >  def _unixdll_getnode():
> >      """Get the hardware address on Unix using ctypes."""
> > @@ -563,6 +567,8 @@ def getnode():
> >      import sys
> >      if sys.platform == 'win32':
> >          getters = _NODE_GETTERS_WIN32
> > +    elif sys.platform == 'uefi':
> > +        getters = []
> >      else:
> >          getters = _NODE_GETTERS_UNIX
> >
> > --
> > 2.32.0.windows.2
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Frinzell, Aaron]

This is great!

Thanks JP for the patch.


Mike,

	Any ETA when this will get merged?

Thanks!

Aaron



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com> 
Sent: Friday, April 8, 2022 1:00 PM
To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

Thanks JP.

That makes sense.  Bypass all the OS specific services in UEFI environment and generate UUID using time and random number.

Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Mike


> -----Original Message-----
> From: Jayaprakash, N <n.jayaprakash@intel.com>
> Sent: Friday, April 8, 2022 10:19 AM
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; 
> Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> + Aaron
> 
> Regards,
> JP
> 
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> Jayaprakash, N
> Sent: 08 April 2022 22:12
> To: Kinney, Michael D <michael.d.kinney@intel.com>; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> The UUID generation is done through the random number generation & 
> time unix time stamp features available through the built-in python modules 'random' and 'time' respectively.
> The random number & time (unix time stamp or epoch) based method of 
> generating the UUID is already there in uuid.py module, with this patch request enabled this path to take effect for UEFI invocation of this module.
> 
> There are some OS specific ways to generate the UUID's such as by 
> using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows.
> These will not work for UEFI and hence added appropriate platform 
> check to ensure that this path is not taken for UEFI invocation.
> 
> Besides this there are MAC address based algorithms available in uuid.py module.
> These algorism are based on reading MAC address through various OS 
> supported methods such as ipconfig command processing, NetBIOS calls 
> on Windows, using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux, NetBSD and other flavours of Linux.
> These are currently not enabled for UEFI invocation of the uuid 
> module. This has been done through platform check added at appropriate place in the uuid.py module code.
> 
> Regards,
> JP
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: 08 April 2022 21:14
> To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>; 
> Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?
> 
> Can you add a description of the technique to the BZ and the commit message?
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
> > Jayaprakash, N
> > Sent: Friday, April 8, 2022 4:52 AM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> > UEFI environment
> >
> >  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> >
> >  This is commit contains the UEFI port of uuid.py module. Made 
> > necessary  changes required to uuid.py module to support UEFI environment.
> >  Porting of this module to UEFI is required for open source tools 
> > such as Chipsec to function properly.
> >
> >  Cc: Rebecca Cran <rebecca@nuviainc.com>
> >  Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> > ---
> >  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
> >  1 file changed, 50 insertions(+), 44 deletions(-)
> >
> > diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > index db8b2ef..84ed0b8 100644
> > --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > @@ -471,57 +471,61 @@ def _netbios_getnode():
> >              continue
> >          return int.from_bytes(bytes, 'big')
> >
> > +
> >  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> >
> >  # If ctypes is available, use it to find system routines for UUID generation.
> >  # XXX This makes the module non-thread-safe!
> >  _uuid_generate_time = _UuidCreate = None
> > -try:
> > -    import ctypes, ctypes.util
> > -    import sys
> > -
> > -    # The uuid_generate_* routines are provided by libuuid on at least
> > -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> > -    _libnames = ['uuid']
> > -    if not sys.platform.startswith('win'):
> > -        _libnames.append('c')
> > -    for libname in _libnames:
> > -        try:
> > -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > -        except Exception:
> > -            continue
> > -        if hasattr(lib, 'uuid_generate_time'):
> > -            _uuid_generate_time = lib.uuid_generate_time
> > -            break
> > -    del _libnames
> > -
> > -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > -    # in issue #8621 the function generates the same sequence of values
> > -    # in the parent process and all children created using fork (unless
> > -    # those children use exec as well).
> > -    #
> > -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> > -    # the test can be adjusted when a later version is fixed.
> > -    if sys.platform == 'darwin':
> > -        if int(os.uname().release.split('.')[0]) >= 9:
> > -            _uuid_generate_time = None
> > -
> > -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > -    # random UUID and UuidCreateSequential gives a UUID containing the
> > -    # hardware address.  These routines are provided by the RPC runtime.
> > -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > -    # to bear any relationship to the MAC address of any network device
> > -    # on the box.
> > +if os.name != 'edk2':
> > +    # This code is not meant to run on UEFI environment
> >      try:
> > -        lib = ctypes.windll.rpcrt4
> > +        import ctypes, ctypes.util
> > +        import sys
> > +
> > +        # The uuid_generate_* routines are provided by libuuid on at least
> > +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> > +        _libnames = ['uuid']
> > +        if not sys.platform.startswith('win'):
> > +            _libnames.append('c')
> > +        for libname in _libnames:
> > +            try:
> > +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > +            except Exception:
> > +                continue
> > +            if hasattr(lib, 'uuid_generate_time'):
> > +                _uuid_generate_time = lib.uuid_generate_time
> > +                break
> > +        del _libnames
> > +
> > +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > +        # in issue #8621 the function generates the same sequence of values
> > +        # in the parent process and all children created using fork (unless
> > +        # those children use exec as well).
> > +        #
> > +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> > +        # the test can be adjusted when a later version is fixed.
> > +        if sys.platform == 'darwin':
> > +            if int(os.uname().release.split('.')[0]) >= 9:
> > +                _uuid_generate_time = None
> > +
> > +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > +        # random UUID and UuidCreateSequential gives a UUID containing the
> > +        # hardware address.  These routines are provided by the RPC runtime.
> > +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > +        # to bear any relationship to the MAC address of any network device
> > +        # on the box.
> > +        try:
> > +            lib = ctypes.windll.rpcrt4
> > +        except:
> > +            lib = None
> > +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > +                              getattr(lib, 'UuidCreate', None))
> >      except:
> > -        lib = None
> > -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > -                          getattr(lib, 'UuidCreate', None))
> > -except:
> > -    pass
> > +        pass
> > +
> >
> >  def _unixdll_getnode():
> >      """Get the hardware address on Unix using ctypes."""
> > @@ -563,6 +567,8 @@ def getnode():
> >      import sys
> >      if sys.platform == 'win32':
> >          getters = _NODE_GETTERS_WIN32
> > +    elif sys.platform == 'uefi':
> > +        getters = []
> >      else:
> >          getters = _NODE_GETTERS_UNIX
> >
> > --
> > 2.32.0.windows.2
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

[Michael D Kinney]

Pushed as 0fdfe217..c32222fe.

Mike


> -----Original Message-----
> From: Frinzell, Aaron <aaron.frinzell@intel.com>
> Sent: Wednesday, April 13, 2022 1:35 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
> This is great!
> 
> Thanks JP for the patch.
> 
> 
> Mike,
> 
> 	Any ETA when this will get merged?
> 
> Thanks!
> 
> Aaron
> 
> 
> 
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Friday, April 8, 2022 1:00 PM
> To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI
> environment
> 
> Thanks JP.
> 
> That makes sense.  Bypass all the OS specific services in UEFI environment and generate UUID using time and random number.
> 
> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Jayaprakash, N <n.jayaprakash@intel.com>
> > Sent: Friday, April 8, 2022 10:19 AM
> > To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>;
> > Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: Frinzell, Aaron <aaron.frinzell@intel.com>
> > Subject: RE: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
> > UEFI environment
> >
> > + Aaron
> >
> > Regards,
> > JP
> >
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > Jayaprakash, N
> > Sent: 08 April 2022 22:12
> > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > devel@edk2.groups.io
> > Subject: Re: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
> > UEFI environment
> >
> > The UUID generation is done through the random number generation &
> > time unix time stamp features available through the built-in python modules 'random' and 'time' respectively.
> > The random number & time (unix time stamp or epoch) based method of
> > generating the UUID is already there in uuid.py module, with this patch request enabled this path to take effect for UEFI
> invocation of this module.
> >
> > There are some OS specific ways to generate the UUID's such as by
> > using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows.
> > These will not work for UEFI and hence added appropriate platform
> > check to ensure that this path is not taken for UEFI invocation.
> >
> > Besides this there are MAC address based algorithms available in uuid.py module.
> > These algorism are based on reading MAC address through various OS
> > supported methods such as ipconfig command processing, NetBIOS calls
> > on Windows, using netstat command in Linux, lanscan in Unix, from arp - address resolution protocol in Linux, NetBSD and
> other flavours of Linux.
> > These are currently not enabled for UEFI invocation of the uuid
> > module. This has been done through platform check added at appropriate place in the uuid.py module code.
> >
> > Regards,
> > JP
> > -----Original Message-----
> > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > Sent: 08 April 2022 21:14
> > To: devel@edk2.groups.io; Jayaprakash, N <n.jayaprakash@intel.com>;
> > Kinney, Michael D <michael.d.kinney@intel.com>
> > Subject: RE: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
> > UEFI environment
> >
> > How is a UUID generated in UEFI env?  Is there a dependency on MAC address or random number generator?
> >
> > Can you add a description of the technique to the BZ and the commit message?
> >
> > Thanks,
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > Jayaprakash, N
> > > Sent: Friday, April 8, 2022 4:52 AM
> > > To: devel@edk2.groups.io
> > > Subject: [edk2-devel] [edk2-libc Patch 1/1]
> > > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for
> > > UEFI environment
> > >
> > >  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> > >
> > >  This is commit contains the UEFI port of uuid.py module. Made
> > > necessary  changes required to uuid.py module to support UEFI environment.
> > >  Porting of this module to UEFI is required for open source tools
> > > such as Chipsec to function properly.
> > >
> > >  Cc: Rebecca Cran <rebecca@nuviainc.com>
> > >  Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > >  Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
> > > ---
> > >  .../Python/Python-3.6.8/Lib/uuid.py           | 94 ++++++++++---------
> > >  1 file changed, 50 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > > b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > > index db8b2ef..84ed0b8 100644
> > > --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > > +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > > @@ -471,57 +471,61 @@ def _netbios_getnode():
> > >              continue
> > >          return int.from_bytes(bytes, 'big')
> > >
> > > +
> > >  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> > >
> > >  # If ctypes is available, use it to find system routines for UUID generation.
> > >  # XXX This makes the module non-thread-safe!
> > >  _uuid_generate_time = _UuidCreate = None
> > > -try:
> > > -    import ctypes, ctypes.util
> > > -    import sys
> > > -
> > > -    # The uuid_generate_* routines are provided by libuuid on at least
> > > -    # Linux and FreeBSD, and provided by libc on Mac OS X.
> > > -    _libnames = ['uuid']
> > > -    if not sys.platform.startswith('win'):
> > > -        _libnames.append('c')
> > > -    for libname in _libnames:
> > > -        try:
> > > -            lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > > -        except Exception:
> > > -            continue
> > > -        if hasattr(lib, 'uuid_generate_time'):
> > > -            _uuid_generate_time = lib.uuid_generate_time
> > > -            break
> > > -    del _libnames
> > > -
> > > -    # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > > -    # in issue #8621 the function generates the same sequence of values
> > > -    # in the parent process and all children created using fork (unless
> > > -    # those children use exec as well).
> > > -    #
> > > -    # Assume that the uuid_generate functions are broken from 10.5 onward,
> > > -    # the test can be adjusted when a later version is fixed.
> > > -    if sys.platform == 'darwin':
> > > -        if int(os.uname().release.split('.')[0]) >= 9:
> > > -            _uuid_generate_time = None
> > > -
> > > -    # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > > -    # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > > -    # random UUID and UuidCreateSequential gives a UUID containing the
> > > -    # hardware address.  These routines are provided by the RPC runtime.
> > > -    # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > > -    # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > > -    # to bear any relationship to the MAC address of any network device
> > > -    # on the box.
> > > +if os.name != 'edk2':
> > > +    # This code is not meant to run on UEFI environment
> > >      try:
> > > -        lib = ctypes.windll.rpcrt4
> > > +        import ctypes, ctypes.util
> > > +        import sys
> > > +
> > > +        # The uuid_generate_* routines are provided by libuuid on at least
> > > +        # Linux and FreeBSD, and provided by libc on Mac OS X.
> > > +        _libnames = ['uuid']
> > > +        if not sys.platform.startswith('win'):
> > > +            _libnames.append('c')
> > > +        for libname in _libnames:
> > > +            try:
> > > +                lib = ctypes.CDLL(ctypes.util.find_library(libname))
> > > +            except Exception:
> > > +                continue
> > > +            if hasattr(lib, 'uuid_generate_time'):
> > > +                _uuid_generate_time = lib.uuid_generate_time
> > > +                break
> > > +        del _libnames
> > > +
> > > +        # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
> > > +        # in issue #8621 the function generates the same sequence of values
> > > +        # in the parent process and all children created using fork (unless
> > > +        # those children use exec as well).
> > > +        #
> > > +        # Assume that the uuid_generate functions are broken from 10.5 onward,
> > > +        # the test can be adjusted when a later version is fixed.
> > > +        if sys.platform == 'darwin':
> > > +            if int(os.uname().release.split('.')[0]) >= 9:
> > > +                _uuid_generate_time = None
> > > +
> > > +        # On Windows prior to 2000, UuidCreate gives a UUID containing the
> > > +        # hardware address.  On Windows 2000 and later, UuidCreate makes a
> > > +        # random UUID and UuidCreateSequential gives a UUID containing the
> > > +        # hardware address.  These routines are provided by the RPC runtime.
> > > +        # NOTE:  at least on Tim's WinXP Pro SP2 desktop box, while the last
> > > +        # 6 bytes returned by UuidCreateSequential are fixed, they don't appear
> > > +        # to bear any relationship to the MAC address of any network device
> > > +        # on the box.
> > > +        try:
> > > +            lib = ctypes.windll.rpcrt4
> > > +        except:
> > > +            lib = None
> > > +        _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > > +                              getattr(lib, 'UuidCreate', None))
> > >      except:
> > > -        lib = None
> > > -    _UuidCreate = getattr(lib, 'UuidCreateSequential',
> > > -                          getattr(lib, 'UuidCreate', None))
> > > -except:
> > > -    pass
> > > +        pass
> > > +
> > >
> > >  def _unixdll_getnode():
> > >      """Get the hardware address on Unix using ctypes."""
> > > @@ -563,6 +567,8 @@ def getnode():
> > >      import sys
> > >      if sys.platform == 'win32':
> > >          getters = _NODE_GETTERS_WIN32
> > > +    elif sys.platform == 'uefi':
> > > +        getters = []
> > >      else:
> > >          getters = _NODE_GETTERS_UNIX
> > >
> > > --
> > > 2.32.0.windows.2
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 
> >