Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 2 Jul 2020 10:05:10 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Andy Lutomirski <luto@kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: objtool clac/stac handling change..
Message-ID: <20200702080510.GY4781@hirez.programming.kicks-ass.net>
References: <CAHk-=wizu7DA7EDrsHQLmkTFBvCRxNyPMHaeMDYMF_U75s9RvQ@mail.gmail.com>
 <5F1767D0-416A-4BA4-9DFF-E82D1EA3F5EE@amacapital.net>
 <20200701205108.wtgfnijav7lgfiqe@treble>
 <CAHk-=wiY-67yt4kGd2EW-7kChQgnLHZ_2aJ+=ps7i7rCz894PQ@mail.gmail.com>
 <20200702000041.movaiqpyzdmhlu67@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200702000041.movaiqpyzdmhlu67@treble>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jul 01, 2020 at 07:00:41PM -0500, Josh Poimboeuf wrote:
> On Wed, Jul 01, 2020 at 02:02:42PM -0700, Linus Torvalds wrote:
> > So the objtool rule might be:
> > 
> >  - in a STAC region, no exception handlers at all except for that
> > ex_handler_uaccess case
> > 
> >  - and that case will clear AC if it triggers.
> > 
> > and maybe such an objtool check would show some case where I'm wrong,
> > and we do some MSR read other other fault thing within a STAC region.
> > That _sounds_ wrong to me, but maybe we have reason to do so that I
> > just can't think or right now?
> 
> Here's an attempt at implementing this, in case anybody wants to play
> with it.  Usual disclaimers apply...

Looks about right, two niggles below.

> @@ -2335,6 +2340,35 @@ static void fill_alternative_cfi(struct objtool_file *file, struct instruction *
>  	}
>  }
>  
> +static int handle_stac(struct symbol *func, struct instruction *insn,
> +		       struct insn_state *state)
> +{
> +	if (state->uaccess) {
> +		WARN_FUNC("recursive UACCESS enable", insn->sec, insn->offset);
> +		return -1;
> +	}
> +
> +	state->uaccess = true;
> +	return 0;
> +}
> +
> +static int handle_clac(struct symbol *func, struct instruction *insn,
> +		       struct insn_state *state)
> +{
> +	if (!state->uaccess && func) {
> +		WARN_FUNC("redundant UACCESS disable", insn->sec, insn->offset);
> +		return -1;
> +	}
> +
> +	if (func_uaccess_safe(func) && !state->uaccess_stack) {
> +		WARN_FUNC("UACCESS-safe disables UACCESS", insn->sec, insn->offset);
> +		return -1;
> +	}
> +
> +	state->uaccess = false;
> +	return 0;
> +}

For both these we return -1 on error and then all callers convert it to
1. So why not have this return 1 and pass any !0 value through?

>  /*
>   * Follow the branch starting at the given instruction, and recursively follow
>   * any other branches (jumps).  Meanwhile, track the frame pointer state at
> @@ -2393,6 +2427,17 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  				if (alt->skip_orig)
>  					skip_orig = true;
>  
> +				if (alt->exception) {
> +					if (!alt->uaccess && state.uaccess) {
> +						WARN_FUNC("non-user-access exception with uaccess enabled",
> +							  sec, insn->offset);
> +						return 1;
> +					}

This is Linus' new rule that AC code should not get any exceptions
except ex_handler_uaccess.

> +
> +					if (alt->uaccess && handle_clac(func, insn, &state))
> +						return 1;

And this is ex_handler_uaccess() mucking with regs->flags, right? Might
want a comment.

> +				}
> +
>  				ret = validate_branch(file, func, alt->insn, state);
>  				if (ret) {
>  					if (backtrace)