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

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

On Tue, Aug 13, 2019 at 11:10:27AM +0200, Laszlo Ersek wrote:
> On 08/12/19 20:43, Roman Kagan wrote:
> > 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 it looks like the issue can't be solved without making OpenSSL aware
> of this use case.

Is reloading the module from scratch ruled out completely?

I'd try to cook up a patch for that unless there's a strong no-go.

Thanks,
Roman.