* CC_STACKPROTECTOR vs CC_STACKPROTECTOR_ALL
@ 2009-04-29 19:54 Kees Cook
2009-04-29 20:24 ` Ingo Molnar
0 siblings, 1 reply; 2+ messages in thread
From: Kees Cook @ 2009-04-29 19:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin
Hi,
What is the rationale for why CC_STACKPROTECTOR_ALL is forced when using
CC_STACKPROTECTOR? I would have expected _ALL to be a separate option
(as it was in earlier versions), but it seems it is forced on by commit
113c5413cf9051cc50b88befdc42e3402bb92115.
Thanks,
-Kees
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: CC_STACKPROTECTOR vs CC_STACKPROTECTOR_ALL
2009-04-29 19:54 CC_STACKPROTECTOR vs CC_STACKPROTECTOR_ALL Kees Cook
@ 2009-04-29 20:24 ` Ingo Molnar
0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2009-04-29 20:24 UTC (permalink / raw)
To: Kees Cook, Arjan van de Ven, Tejun Heo
Cc: linux-kernel, Thomas Gleixner, H. Peter Anvin
* Kees Cook <kees@ubuntu.com> wrote:
> Hi,
>
> What is the rationale for why CC_STACKPROTECTOR_ALL is forced when
> using CC_STACKPROTECTOR? I would have expected _ALL to be a
> separate option (as it was in earlier versions), but it seems it
> is forced on by commit 113c5413cf9051cc50b88befdc42e3402bb92115.
it used to be a separate option. I merged them into one, because we
had too many options really, and because the vmsplice exploit would
only have been caught by the _ALL variant. So the 'light' variant
never really worked well IMO.
Ingo
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-04-29 20:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-29 19:54 CC_STACKPROTECTOR vs CC_STACKPROTECTOR_ALL Kees Cook
2009-04-29 20:24 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®