[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] Fix building error
On 01/19/2015 11:23 PM, Ian Campbell wrote: > 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. I don't understand your suggestion. > > 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). Building problems only affect developers, so I think we should fix this problem. If the developers add extra flags to define the macro _FORTIFY_SOURCE, it also breaks building. We can disable debug for such case, or undefine the macro in Rules.mk. If the macro _FORTIFY_SOURCE is not defined, undefining it is harmless. Thanks Wen Congyang > > Ian. > > . > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |