Messages in this thread | | | From | Kees Cook <> | Date | Mon, 10 Sep 2018 21:30:49 -0700 | Subject | Re: get_arg_page() && ptr_size accounting |
| |
On Mon, Sep 10, 2018 at 10:43 AM, Oleg Nesterov <oleg@redhat.com> wrote: > On 09/10, Oleg Nesterov wrote: >> >> On 09/10, Kees Cook wrote: >> > >> > On Mon, Sep 10, 2018 at 9:41 AM, Kees Cook <keescook@chromium.org> wrote: >> > > On Mon, Sep 10, 2018 at 5:29 AM, Oleg Nesterov <oleg@redhat.com> wrote: >> > >> Hi Kees, >> > >> >> > >> I was thinking about backporting the commit 98da7d08850fb8bde >> > >> ("fs/exec.c: account for argv/envp pointers"), but I am not sure >> > >> I understand it... >> > >> > BTW, if you backport that, please get the rest associated with the >> > various Stack Clash related weaknesses: >> >> may be... >> >> > da029c11e6b1 exec: Limit arg stack to at most 75% of _STK_LIM >> >> and I have to admit that I do not understand this patch at all, the >> changelog explains nothing. >> >> Could you explain what this patch actually prevents from? Especially >> now that we have stack_guard_gap? > > forgot to mention... > > with this patch > > #define MAX_ARG_STRINGS 0x7FFFFFFF > > doesn't match the reality. perhaps something like below makes sense just > to make it clear, but this is cosmetic.
Part of the discussion from back then was basically "we don't have hard-coded limits so programs need to check dynamically themselves".
I'd prefer to leave it all well enough alone since I don't want to introduce regressions here in the face of the many many Stack Clash style weaknesses.
-Kees
-- Kees Cook Pixel Security
| |