Re: [edk2-devel] static data in dxe_runtime modules

["Roman Kagan" <rkagan@virtuozzo.com>]

On Fri, Aug 09, 2019 at 04:07:00PM +0000, Roman Kagan via Groups.Io wrote:
> On Thu, Aug 08, 2019 at 07:39:14PM +0200, Laszlo Ersek wrote:
> > On 08/07/19 19:41, Andrew Fish wrote:
> > >> On Aug 7, 2019, at 10:29 AM, Laszlo Ersek <lersek@redhat.com> wrote:
> > >> On 08/05/19 12:18, Roman Kagan wrote:
> > >>> On Sat, Aug 03, 2019 at 04:03:04AM +0200, Laszlo Ersek via Groups.Io wrote:
> > >>>> On 08/01/19 21:16, Roman Kagan wrote:
> > >> I'm convinced that OpenSSL needs to expose a new API for this particular
> > >> problem.
> 
> Since, as you point out below, the problem only affects the essentially
> broken configuration (SECURE_BOOT_ENABLE && !SMM_REQUIRE), I'm fine with
> saving time and effort and sticking to the hack-ish approach proposed in
> the bugzilla issue, which is to iterate over "thread-local" pointers and
> EfiConvertPointer() on each.  (As long as it fixes the problem of
> course; I'll test and report back.)

It doesn't :(  It just gets slightly further and hits another static
pointer variable which is not part of the thread-local array:

...
  Pkcs7Verify
    EVP_add_digest
      OBJ_NAME_add

this one uses a few static pointer variables that are also initialized
on demand and become stale upon SetVirtualAddressMap().

> So we should be good without a new API from OpenSSL.

> > In other words, the problem doesn't exist when OpenSSL (with the rest of
> > the variable driver stack) is protected with SMM, as pointers into SMRAM
> > remain valid "forever", after the initial SMM driver dispatch.
> 
> Makes perfect sense.  We happen to build this broken configuration for
> some historical reasons, I'm failing to recall exactly which.  Will try
> to get rid of it.

We appear to have some i440fx-based VMs with SecureBoot in the field
(dunno about their origin) and those don't allow SMM.

Thanks,
Roman.