Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87woyybu73.fsf@e105548-lin.cambridge.arm.com>
Date: Tue, 27 Feb 2018 10:30:56 +0000
From: Richard Sandiford <richard.sandiford@....com>
To: Laura Abbott <labbott@...hat.com>
Cc: <alex.popov@...ux.com>,  Kees Cook <keescook@...omium.org>,  <kernel-hardening@...ts.openwall.com>,  Will Deacon <will.deacon@....com>
Subject: Re: [PATCH 2/2] gcc-plugins: stackleak: Update for gcc-8

Laura Abbott <labbott@...hat.com> writes:
> On 02/24/2018 06:04 AM, Alexander Popov wrote:
>> Hello Laura,
>> 
>> Thanks for the cooperation!
>> 
>> On 23.02.2018 02:14, Laura Abbott wrote:
>>> +#if BUILDING_GCC_VERSION >= 8000
>>> +bool check_frame_size()
>>> +{
>>> +	return maybe_ge(get_frame_size(), track_frame_size);
>> 
>> After looking through this guide
>> https://gcc.gnu.org/onlinedocs//gccint/Guidelines-for-using-poly_005fint.html#Guidelines-for-using-poly_005fint
>> it seems to me that we should better use something like that:
>> 
>> poly_int64 frame_size = get_frame_size();
>> 
>> if (frame_size.to_constant() >= track_frame_size)
>> 	return 0;
>> 
>> May I ask for your opinion?
>> 
>
> I was a bit wary of using to_constant() because I wasn't 100% sure
> I could make the assertion that it could actually be a constant so using

Yeah, the assert would fire for SVE functions that spill SVE registers
to the stack.

> maybe_ge seemed like the conservative approach. This also getting into
> compiler internals so it's possible I'm misunderstanding how poly_ints
> are supposed to work.

The maybe_ge patch looks good to me FWIW.

Thanks,
Richard

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.