linux-kernel - Re: [RFC][PATCH 01/14 v2] function_graph: Convert ret

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 May 2019 08:05:53 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Andy Lutomirski <luto@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Namhyung Kim <namhyung@...nel.org>,
        "Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: [RFC][PATCH 01/14 v2] function_graph: Convert ret_stack to a
 series of longs

On Fri, 24 May 2019 13:11:44 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Mon, May 20, 2019 at 10:20:02AM -0400, Steven Rostedt wrote:
> 
> > +#define FGRAPH_RET_SIZE (sizeof(struct ftrace_ret_stack))
> > +#define FGRAPH_RET_INDEX (ALIGN(FGRAPH_RET_SIZE, sizeof(long)) / sizeof(long))  
> 
> I think you want to write that like:
> 
> 	BUILD_BUG_ON(sizeof(ftrace_ret_stack) % sizeof(long));

Sure.

> 
> It'd be very weird for that sizeof not to be right.

Agreed, but I was paranoid. The BUILD_BUG_ON() would also work.

> 
> > +#define SHADOW_STACK_SIZE (PAGE_SIZE)  
> 
> Do we really need that big a shadow stack?

Well, this is a sticky point. I allow up to 16 users at a time
(although I can't imagine more than 5, but you never know), and each
user adds a long and up to 4 more words (which is probably unlikely
anyway). And then we can have deep call stacks (we are getting deeper
each release it seems).

I figured, I start with a page size, and then in the future we can make
it dynamic, or shrink it if it proves to be too much.

> 
> > +#define SHADOW_STACK_INDEX			\
> > +	(ALIGN(SHADOW_STACK_SIZE, sizeof(long)) / sizeof(long))
> > +/* Leave on a buffer at the end */
> > +#define SHADOW_STACK_MAX_INDEX (SHADOW_STACK_INDEX - FGRAPH_RET_INDEX)
> > +
> > +#define RET_STACK(t, index) ((struct ftrace_ret_stack *)(&(t)->ret_stack[index]))
> > +#define RET_STACK_INC(c) ({ c += FGRAPH_RET_INDEX; })
> > +#define RET_STACK_DEC(c) ({ c -= FGRAPH_RET_INDEX; })  
> 
> I'm thinking something like:
> 
> #define RET_PUSH(s, val)				\
> do {							\
> 	(s) -= sizeof(val);				\
> 	(typeof(val) *)(s) = val;			\
> } while (0)
> 
> #define RET_POP(s, type)				\
> ({							\
> 	type *__ptr = (void *)(s);			\
> 	(s) += sizeof(type);				\
> 	*__ptr;						\
> })
> 
> Would me clearer?

Due to races with interrupts, and this not being an atomic operation, I
had to play tricks with moving the stack pointer and adding data to it.
So I wanted to keep the changing of the stack pointer and adding and
retrieving of the stack data separate.

Later patches remove the RET_STACK_INC/DEC() anyway.

Thanks for taking the time to look at these patches!

-- Steve