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:   Mon, 29 Jun 2020 19:10:22 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     x86@...nel.org, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Andy Lutomirski <luto@...capital.net>,
        Jethro Beekman <jethro@...tanix.com>,
        akpm@...ux-foundation.org, andriy.shevchenko@...ux.intel.com,
        asapek@...gle.com, cedric.xing@...el.com, chenalexchen@...gle.com,
        conradparker@...gle.com, cyhanish@...gle.com,
        dave.hansen@...el.com, haitao.huang@...el.com,
        josh@...htriplett.org, kai.huang@...el.com, kai.svahn@...el.com,
        kmoy@...gle.com, ludloff@...gle.com, luto@...nel.org,
        nhorman@...hat.com, npmccallum@...hat.com, puiterwijk@...hat.com,
        rientjes@...gle.com, tglx@...utronix.de, yaozhangx@...gle.com
Subject: Re: [PATCH v33 15/21] x86/vdso: Add support for exception fixup in
 vDSO functions

On Thu, Jun 18, 2020 at 01:08:37AM +0300, Jarkko Sakkinen wrote:
...
> intended benefit of massaging GCC's inlining algorithm is unlikely to
> realized in the vDSO any time soon, if ever.

That is a very good explanation and I would prefer if it would be in a
sgx-specific README or so instead of it getting lost in git...

> +bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
> +			  unsigned long error_code, unsigned long fault_addr)
> +{
> +	const struct vdso_image *image = current->mm->context.vdso_image;
> +	const struct vdso_exception_table_entry *extable;
> +	unsigned int nr_entries, i;
> +	unsigned long base;
> +
> +	/*
> +	 * Do not attempt to fixup #DB or #BP.  It's impossible to identify
> +	 * whether or not a #DB/#BP originated from within an SGX enclave and
> +	 * SGX enclaves are currently the only use case for vDSO fixup.
> +	 */

So this is all fine and dandy but nowhere do I see the code doing:

	if (am_I_an_sgx_enclave(tsk))
		fixup_vdso_exception()

because that vDSO exception fixup, albeit it looking kinda generic, is
SGX-only for now. So it should be designed to run only for SGX enclaves
for now.

Also, is there any particular reason for fixup_vdso_exception() to be in
arch/x86/entry/vdso/extable.c instead of in arch/x86/mm/extable.c?

I mean, it gets called by traps.c so it looks like normal kernel code to
me or am I missing some vdso magic?

And built only when CONFIG_INTEL_SGX is enabled.

And so on...

...

> diff --git a/arch/x86/entry/vdso/extable.h b/arch/x86/entry/vdso/extable.h
> new file mode 100644
> index 000000000000..aafdac396948
> --- /dev/null
> +++ b/arch/x86/entry/vdso/extable.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __VDSO_EXTABLE_H
> +#define __VDSO_EXTABLE_H
> +
> +/*
> + * Inject exception fixup for vDSO code.  Unlike normal exception fixup,
> + * vDSO uses a dedicated handler the addresses are relative to the overall
> + * exception table, not each individual entry.
> + */
> +#ifdef __ASSEMBLY__
> +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> +	ASM_VDSO_EXTABLE_HANDLE from to
> +
> +.macro ASM_VDSO_EXTABLE_HANDLE from:req to:req
> +	.pushsection __ex_table, "a"
> +	.long (\from) - __ex_table
> +	.long (\to) - __ex_table
> +	.popsection
> +.endm
> +#else
> +#define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
> +	".pushsection __ex_table, \"a\"\n"      \
> +	".long (" #from ") - __ex_table\n"      \
> +	".long (" #to ") - __ex_table\n"        \
> +	".popsection\n"
> +#endif
> +
> +#endif /* __VDSO_EXTABLE_H */
> +

.git/rebase-apply/patch:122: new blank line at EOF.
+

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ