[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
> 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).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.