Re: [edk2-devel] [PATCH 00/14] Implement Dynamic Memory Protections

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> > Can we have both?
> > 
> > Being able to adjust settings at runtime is great.  But being able to
> > set them at compile time on the command line (via build --pcd), without
> > patching code, is very useful too.
> > 
> > I'd suggest to keep the PCDs, create a profile from PCD settings and use
> > that profile by default.  At least for the transition phase and while we
> > don't have good support (yet) to actually manage profiles.
> 
> Hey, Gerd.
> 
> The idea to keep PCDs around as another method of configuring protections is
> good, but I don't think there would be a way to tell if a zero-ed PCD value
> was an explicit setting or just the default without adding another PCD to
> indicate which value should be used. I think if the HOB is produced by the
> platform those settings should be used by default. Is that what you're
> envisioning as well?

See below, I'll come back to that in a moment.

> > Speaking of profile management: What is the longer-term vision here?

> There are lots of ways OEMs might want to configure their platform security
> and I think it's an open question what sorts of profile management tools
> would be useful to add to EDK2.

I think it makes sense to have the concept of named profiles in edk2.
Right now there are a bunch of #defines with profiles, I think it would
be nice to have names and descriptions attached to them.  Could be as
simple as an array in the library:

struct {
   CHAR16 *Name;
   CHAR16 *Description;
   DXE_MEMORY_PROTECTION_SETTINGS Settings;
} MemoryProtectionProfiles[] = {
   {
      .Name        = "debug",
      .Description = "development profile",
      .Settings    = DXE_MEMORY_PROTECTION_SETTINGS_DEBUG,
   },{
      /* ... */
   }
}

Platforms could just loop over the list and add the profiles to the
platform configuration menu in uefi firmware settings.  Maybe it makes
sense to have a MemoryProtectionConfigDxe instead so platforms can
easily share the Hii code for that.

One of the profiles could be created from PCDs:

    {
	.Name               = "pcd",
	.Description        = "legacy PCD based settings",
	.Settings.PoolGuard = PcdGetU32(PcdHeapGuardPoolType),
        /* ... */
    }

> > For virtual machine firmware it a good idea to allow picking up the
> > profile configuration from the host.  For qemu that can use fw_cfg,
> > similar to the PcdSetNxForStack option we have today.
> 
> I don't have much experience using the fw_cfg so I'd need to look into the
> details, but would it make sense to expand the options which can be passed
> via fw_cfg to be the gamut of memory protection configuration settings?

I think being able to select a named profile is good enough, for example
this way:

qemu -fw_cfg name=opt/org.tianocore/MemoryProtectionProfile,string=debug

> > > This patch series also increases the memory protection level for OvmfPkg and
> > > ArmVirtPkg.
> > 
> > Not a good idea, especially not using the 'debug' profile (which turns
> > on all guard bits) because that slows down firmware boot alot.
> 
> I haven't done performance testing, but I don't notice much slowdown.

Page guard isn't much of a problem.

Heap guard has significant overhead in both performance and memory
usage.

> Isn't development the primary use case for these virtual platforms?

Development is surely one important use case   Linux-based VM hosting
often runs OVMF in production though.

> Is there
> another profile you think would work better?

"pcd" (or "production") would IMHO be a better default.

thanks & take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106963): https://edk2.groups.io/g/devel/message/106963
Mute This Topic: https://groups.io/mt/100090629/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-