Re: Drop CSM support in OvmfPkg?

["Ni, Ray" <ray.ni@intel.com>]

David,
I'd like to re-start the discussion.
Could you please kindly explain the background/reason of adding CSM support in OVMF?
Maybe knowing the reason can help to make further decisions of whether to
A. keep it outside OvmfPkg
B. keep it inside OvmfPkg
C. maybe have a chance to just remove the CSM support after revisiting

Thanks,
Ray

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ni,
> Ruiyu
> Sent: Thursday, December 20, 2018 10:55 PM
> To: David Woodhouse <dwmw2@infradead.org>; Gerd Hoffmann
> <kraxel@redhat.com>; Laszlo Ersek <lersek@redhat.com>; Richardson, Brian
> <brian.richardson@intel.com>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> Kevin O'Connor <kevin@koconnor.net>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: Re: [edk2] Drop CSM support in OvmfPkg?
> 
> 
> 
> > -----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.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel