|
[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 |