Re: Drop CSM support in OvmfPkg?

["Ni, Ruiyu" <ruiyu.ni@intel.com>]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Thursday, December 20, 2018 9:37 PM
> To: Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek <lersek@redhat.com>
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>;
> Anthony Perard <anthony.perard@citrix.com>; Julien Grall
> <julien.grall@linaro.org>; edk2-devel@lists.01.org; Kevin O'Connor
> <kevin@koconnor.net>
> Subject: Re: Drop CSM support in OvmfPkg?
> 
> On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote:
> > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> > > (Adding Kevin, Gerd, David)
> > >
> > > On 12/17/18 03:23, Ni, Ruiyu wrote:
> > > > Hi OvmfPkg maintainers and reviewers,
> > > > I am working on removing IntelFrameworkModulePkg and
> IntelFrameworkPkg. The biggest dependency now I see is the CSM components
> that OVMF depends on.
> > > > So I'd like to know your opinion about how to handle this. I see two
> options here:
> > > >
> > > >   1.  Drop CSM support in OvmfPkg.
> > > >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > > >
> > > > What's your opinion about this?
> > >
> > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
> > > and Fedora also don't enable the CSM (mainly because I had found
> > > debugging & supporting the CSM *extremely* difficult). For
> > > virtualization, we generally recommend "use SeaBIOS directly if you need
> > > a traditional BIOS guest".
> >
> > On a virtual machine it is very simple to switch the firmware (unlike on
> > physical machines), which I think is the main reason ovmf+csm never
> > really took off.
> 
> Hm, that's true for virtual machines where you own the host system too
> and switching BIOS is just a matter of configuration. If you're running
> VM hosting at scale, however, and the customers don't get that level of
> control, then offering a single BIOS image which does UEFI and CSM in a
> "one size fits all" does have some merit.
> 
> > > (3) However, David and Kevin had put a *lot* of work into enabling
> > > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
> > > target is a dedicated / separate "build mode" of SeaBIOS.
> >
> > IIRC there are still some corner cases which are not working and nobody
> > wants put any effort into fixing them.  S3 suspend comes to mind.
> 
> Don't think that should be hard to fix if anyone really cares...
> 
> > I'm not even sure it still works.  It builds, yes, my jenkins instance
> > does that.  But there is no testing beyond that, and I doubt that
> > someone else does regular ovmf+csm regression testing.  So the chances
> > that any runtime breakage goes unnoticed are pretty high ...
> >
> > > (4) I also think an open source CSM implementation should exist, just so
> > > people can study it and experiment with it.
> >
> > It'll not be deleted from git, so it'll be there even when removed from
> > master branch.
> >
> > > In short, I think the community would benefit if someone continued to
> > > maintain the CSM infrastructure in edk2,
> 
> Ruiyu (and Jordan), what's actually happening here? You said you were
> deprecating IntelFrameworkPkg... in the internal Intel builds, what
> replaces the CSM part? We fought to get parts of CSM support published
> to TianoCore from the internal tree, and I'm concerned that this is a
> regression — we end up with CSM support only being internal again. Or
> is it being dropped from the Intel tree entirely?

UEFI secure boot enabled firmware is the very recommended pre-OS
environment considering nowadays more and more hackers are interested
in this area.
CSM enabled UEFI environment just cannot provide a trust chain up to OS loader
and it will be (or may be) deprecated.
I believe this is the major reason that we want to remove CSM support.
@Brian, correct me if I am wrong.

Regarding to deprecating IntelFrameworkPkg, that's to remove old used
interfaces/codes to make developers easier to under EDKII project.

> 
> I am very much against *increasing* the number of features which are
> supported in private repositories and not the public one.