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" <n.jayaprakash@intel.com>]

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
> 
> 
> 
> 
>