linux-kernel - RE: [RFC PATCH 21/32] x86/fred: FRED entry/exit and dispatch code

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:   Wed, 21 Dec 2022 02:56:08 +0000
From:   "Li, Xin3" <xin3.li@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: RE: [RFC PATCH 21/32] x86/fred: FRED entry/exit and dispatch code


> > +static DEFINE_FRED_HANDLER(fred_exception)
> > +{
> > +	/*
> > +	 * This intentially omits exceptions that cannot happen on FRED h/w:
> > +	 * vectors _NOT_ listed are set to NULL.
> > +	 */
> > +	static const fred_handler
> exception_handlers[NUM_EXCEPTION_VECTORS] = {
> > +		[X86_TRAP_DE] = fred_exc_divide_error,
> > +		[X86_TRAP_DB] = fred_exc_debug,
> > +		[X86_TRAP_NMI] = NULL, /* A separate event type, not handled
> here */
> > +		[X86_TRAP_BP] = exc_int3,
> > +		[X86_TRAP_OF] = fred_exc_overflow,
> > +		[X86_TRAP_BR] = fred_exc_bounds,
> > +		[X86_TRAP_UD] = exc_invalid_op,
> > +		[X86_TRAP_NM] = fred_exc_device_not_available,
> > +		[X86_TRAP_DF] = fred_exc_double_fault,
> > +		[X86_TRAP_OLD_MF] = NULL, /* 387 only! */
> > +		[X86_TRAP_TS] = fred_exc_invalid_tss,
> > +		[X86_TRAP_NP] = fred_exc_segment_not_present,
> > +		[X86_TRAP_SS] = fred_exc_stack_segment,
> > +		[X86_TRAP_GP] = fred_exc_general_protection,
> > +		[X86_TRAP_PF] = fred_exc_page_fault,
> > +		[X86_TRAP_SPURIOUS] = NULL, /* Interrupts are their own event
> type */
> > +		[X86_TRAP_MF] = fred_exc_coprocessor_error,
> > +		[X86_TRAP_AC] = fred_exc_alignment_check,
> > +		[X86_TRAP_MC] = fred_exc_machine_check,
> > +		[X86_TRAP_XF] = fred_exc_simd_coprocessor_error
> > +	};
> > +	static const u32 noinstr_mask = BIT(X86_TRAP_DB) | BIT(X86_TRAP_BP) |
> > +					BIT(X86_TRAP_DF) | BIT(X86_TRAP_PF) |
> > +					BIT(X86_TRAP_MC) | BIT(X86_TRAP_UD);
> > +	u8 vector = array_index_nospec((u8)regs->vector,
> NUM_EXCEPTION_VECTORS);
> > +	irqentry_state_t state;
> > +
> > +	if (likely(exception_handlers[vector])) {
> 
> Can't you get rid of this branch by stuffing the exception_handlers[] table with
> fred_bad_event?
> 
> > +		if (!(BIT(vector) & noinstr_mask)) {
> > +			state = irqentry_enter(regs);
> > +			instrumentation_begin();
> > +		}
> > +
> > +		exception_handlers[vector](regs);
> > +
> > +		if (!(BIT(vector) & noinstr_mask)) {
> > +			instrumentation_end();
> > +			irqentry_exit(regs, state);
> > +		}
> 
> This noinstr mask is daft; why not have DEFINE_FRED_HANDLER and
> DEFINE_FRED_HANDLER_RAW or something, have the normal one include the
> irqentry bits and use the _RAW one for the 'funny' ones that need to do it
> themselves?

I wanted to keep "state = irqentry_enter(regs); instrumentation_begin();"
in the dispatch framework, instead of pushing down to the handlers.

Of course, we could do it the other way if it is more preferred.

#PF is way more frequent than other events, maybe we should do an early
out for it in fred_entry_from_user/kernel().

> 
> > +	} else {
> > +		return fred_bad_event(regs);
> > +	}
> 
> Then all this becomes:
> 
> 	exception_handlers[vector](regs);
> 
> no branches, no nothing.

This does look simpler and cleaner at the dispatch framework layer.

Xin