From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: "devel@edk2.groups.io" <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
Date: Fri, 8 Apr 2022 15:43:42 +0000 [thread overview]
Message-ID: <CO1PR11MB492959BEB8ED7999C6853961D2E99@CO1PR11MB4929.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220408115209.2002-2-n.jayaprakash@intel.com>
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
>
>
>
>
>
next prev parent reply other threads:[~2022-04-08 15:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 11:52 [edk2-libc Patch 0/1] added support for uuid.py module for uefi environment Jayaprakash, N
2022-04-08 11:52 ` [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment Jayaprakash, N
2022-04-08 15:43 ` Michael D Kinney [this message]
2022-04-08 16:41 ` [edk2-devel] " Jayaprakash, N
[not found] ` <16E3F967D40E1D33.6238@groups.io>
2022-04-08 17:19 ` Jayaprakash, N
2022-04-08 18:00 ` Michael D Kinney
2022-04-12 11:35 ` Jayaprakash, N
2022-04-13 20:35 ` Frinzell, Aaron
2022-04-13 23:37 ` Michael D Kinney
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=CO1PR11MB492959BEB8ED7999C6853961D2E99@CO1PR11MB4929.namprd11.prod.outlook.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