* Maxim Kuvyrkov:
> The problem is fairly target-dependent, so architecture maintainers
> need to look at how stack-guard canaries and their addresses are
> handled and whether they can be spilled onto stack.
>
> It appears we need to poll architecture maintainers before filing the CVE.
One CVE I
> On Apr 29, 2018, at 2:11 PM, Florian Weimer wrote:
>
> * Maxim Kuvyrkov:
>
>>> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote:
>>>
>>> * Thomas Preudhomme:
>>>
Yes absolutely, CSE needs to be avoided. I made memory access volatile
because the change was easier to do. Also on Ar
* Maxim Kuvyrkov:
>> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote:
>>
>> * Thomas Preudhomme:
>>
>>> Yes absolutely, CSE needs to be avoided. I made memory access volatile
>>> because the change was easier to do. Also on Arm Thumb-1 computing the
>>> guard's address itself takes several lo
> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote:
>
> * Thomas Preudhomme:
>
>> Yes absolutely, CSE needs to be avoided. I made memory access volatile
>> because the change was easier to do. Also on Arm Thumb-1 computing the
>> guard's address itself takes several loads so had to modify some
* Thomas Preudhomme:
> Yes absolutely, CSE needs to be avoided. I made memory access volatile
> because the change was easier to do. Also on Arm Thumb-1 computing the
> guard's address itself takes several loads so had to modify some more
> patterns. Anyway, regardless of the proper fix, do you ha
Yes absolutely, CSE needs to be avoided. I made memory access volatile
because the change was easier to do. Also on Arm Thumb-1 computing the
guard's address itself takes several loads so had to modify some more
patterns. Anyway, regardless of the proper fix, do you have any objection
to raising a
On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote:
> On x86 yes, it's actually done in the same instruction that's doing the
> comparison if I'm not mistaken. That is not the case for arm and aarch64
> though where loading the canari is done separately from the comparison and
> does
On x86 yes, it's actually done in the same instruction that's doing the
comparison if I'm not mistaken. That is not the case for arm and aarch64
though where loading the canari is done separately from the comparison and
does not involve an offset. Computing the address from which to do the load
is
On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote:
> It's not the canari which is spilled in this case, but the address to the
> canari. Which means an attacker could make it point to something else than
> the real canari.
When the canary is in TLS area, it is usually small constan
It's not the canari which is spilled in this case, but the address to the
canari. Which means an attacker could make it point to something else than
the real canari.
On 27 April 2018 at 13:16, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas Preudhomme wrote:
> > For stack
On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas Preudhomme wrote:
> For stack protector to be robust, at no point in time the guard against
> which the canari is compared must be spilled to the stack. This is achieved
> by having dedicated insn pattern for setting the canari and comparing it
> aga
Hi there,
Any objection to filing a CVE for that?
Best regards,
Thomas
On 19 April 2018 at 18:17, Thomas Preudhomme
wrote:
> Hi,
>
> For stack protector to be robust, at no point in time the guard against
> which the canari is compared must be spilled to the stack. This is achieved
> by havin
Hi,
For stack protector to be robust, at no point in time the guard against
which the canari is compared must be spilled to the stack. This is achieved
by having dedicated insn pattern for setting the canari and comparing it
against the guard which doesn't reflect at RTL what is happening. However
13 matches
Mail list logo
