public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Frinzell, Aaron" <aaron.frinzell@intel.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Jayaprakash, N" <n.jayaprakash@intel.com>,
	"devel@edk2.groups.io" <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
Date: Wed, 13 Apr 2022 20:35:04 +0000	[thread overview]
Message-ID: <SN6PR11MB3535373CB38FE43BC2785CA99EEC9@SN6PR11MB3535.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CO1PR11MB49290D320FBB625B3D835B23D2E99@CO1PR11MB4929.namprd11.prod.outlook.com>

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


  parent reply	other threads:[~2022-04-13 20:35 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
2022-04-08 18:00         ` Michael D Kinney
2022-04-12 11:35           ` Jayaprakash, N
2022-04-13 20:35           ` Frinzell, Aaron [this message]
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=SN6PR11MB3535373CB38FE43BC2785CA99EEC9@SN6PR11MB3535.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