From: "Jayaprakash, N" <n.jayaprakash@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>
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
Date: Fri, 8 Apr 2022 17:19:20 +0000 [thread overview]
Message-ID: <PH7PR11MB5943D601CCE67AA8CE84F6F4EEE99@PH7PR11MB5943.namprd11.prod.outlook.com> (raw)
In-Reply-To: <16E3F967D40E1D33.6238@groups.io>
+ 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
>
>
>
>
>
next prev parent reply other threads:[~2022-04-08 17:19 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 ` [edk2-devel] " Michael D Kinney
2022-04-08 16:41 ` Jayaprakash, N
[not found] ` <16E3F967D40E1D33.6238@groups.io>
2022-04-08 17:19 ` Jayaprakash, N [this message]
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=PH7PR11MB5943D601CCE67AA8CE84F6F4EEE99@PH7PR11MB5943.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