* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 14 Feb 2008 at 17:35, Jakub Jelinek wrote:
>
> > Where do you see a mispredicted branch?
>
> try it with -Os (gentoo gcc 4.2.2):
>
> :
>0: 48 83 ec 58 sub$0x58,%rsp
>4: 65 48 8b 04 25 28 00 00 00
* Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote:
> > The per function call overhead from stackprotector is already pretty
> > serious IMO, but at least that's something that GCC _could_ be doing
> > (much) smarter (why doesnt it jne forwa
On 14 Feb 2008 at 17:35, Jakub Jelinek wrote:
> Where do you see a mispredicted branch?
try it with -Os (gentoo gcc 4.2.2):
:
0: 48 83 ec 58 sub$0x58,%rsp
4: 65 48 8b 04 25 28 00 00 00 mov%gs:0x28,%rax
d: 48 89 44 24 48 mov%ra
On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote:
> The per function call overhead from stackprotector is already pretty
> serious IMO, but at least that's something that GCC _could_ be doing
> (much) smarter (why doesnt it jne forward out to __check_stk_failure,
> instead of generati
On 14 Feb 2008 at 21:25, Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > really, the best defense is to reduce the useful lifetime of any
> > leaked canary, and you can't get better than syscall granularity
> > without disproportional effort and impact elsewhere (and i'
On Thu, 14 Feb 2008 21:25:35 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > really, the best defense is to reduce the useful lifetime of any
> > leaked canary, and you can't get better than syscall granularity
> > without disproportional e
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> really, the best defense is to reduce the useful lifetime of any
> leaked canary, and you can't get better than syscall granularity
> without disproportional effort and impact elsewhere (and i'm sure some
> would find even this disproportional ;
On 14 Feb 2008 at 20:00, Ingo Molnar wrote:
> > the best practical defense against leaking the canary is to change its
> > value on every syscall but it has some performance impact in
> > microbenchmarks.
>
> yeah, that's not really practical (especially as it would deplete our
> entropy pool
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> the commit comment says:
>
> > This hack was true up to the point the stackprotector added another
> > word to the stack frame. Shifting all the addresses by 8 bytes,
> > crashing and burning any exec attempt.
>
> actually, that's not the probl
On 14 Feb 2008 at 18:00, Ingo Molnar wrote:
some comments:
> x86: fix execve with -fstack-protect
the commit comment says:
> This hack was true up to the point the stackprotector added
> another word to the stack frame. Shifting all the addresses
> by 8 bytes, crashing and burning any exec at
10 matches
Mail list logo
