Re: [Xen-devel] [PATCH v2] Fix building error

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2015-01-15 at 11:26 +0000, Ian Jackson wrote:
> Wen Congyang writes ("[PATCH v2] Fix building error"):
> >  ifeq ($(debug),y)
> >  # Disable optimizations and enable debugging information for macros
> >  CFLAGS += -O0 -g3
> > +# _FORTIFY_SOURCE requires compiling with optimization
> > +CFLAGS += -Wp,-U_FORTIFY_SOURCE
> 
> I'm not entirely convinced about this.  I have two kinds of concern:
> 
> One is practical, which is that ATM AIUI a debug build, while not
> intended for production use, is not any less secure.  (Leaving aside
> the ability of guests to perform a DoS with copious debugging output.)
> 
> The other is that we seem to be entering into a battle of escalation
> between various Makefiles.  Specifically, this seems to be a
> workaround for a bug in some other Makefiles we are using: the bug
> being that these other Makefiles can't cope with -O0.  And
> unconditionally squashing the other Makefiles' options seems like a
> big hammer.
> 
> The fact that Fortify doesn't support -O0 is a property of Fortify
> which ought to be encoded in Fortify (or the places where it is
> enabled).
> 
> Assuming that the underlying bug is intractible

I think so, see <54B73623.9040503@xxxxxxxxxxxxxx>. I suppose one could
enter into a dialogue with Fedora about the practice of enabling these
flags for all Python modules built on a Fedora system vs. just those
built via RPM etc.

>  I think the right
> answer is for an affected developer

Which will be all developers using Fedora AFAICT.

>  to do one of the following, as a
> workaround: either, manually override Fortify when requesting a debug
> build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the
> -O0 setting.
> 
> To make this easier to do without editing tools/Rules.mk I would
> support a patch to Rules.mk which has it honour a variable containing
> a debug-specific set of CFLAGS.

This seems reasonable enough to me.

The original patch in <54B73658.6030309@xxxxxxxxxxxxxx> (correctly IMHO)
applied the workaround only to the Python parts of the build
(tools/{python,pygrub}) whereas this v2 and your suggestion would affect
all of tools/*. That seems like a reasonable compromise under the
circumstances (the alternative being special overrides for Python or
something, no nice).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel