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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
