From: Mark Rutland <mark.rutland@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Mike Rapoport <rppt@linux.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK
Date: Thu, 24 Jan 2019 17:18:15 +0000 [thread overview]
Message-ID: <20190124171814.GD5531@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <067ad3f669bdf5ad562186e9875b588f25732406.1548346225.git.christophe.leroy@c-s.fr>
On Thu, Jan 24, 2019 at 04:19:43PM +0000, Christophe Leroy wrote:
> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
>
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of stack
> overflows.
> - Its address is harder to determine if stack addresses are
> leaked, making a number of attacks more difficult.
>
> This has the following consequences:
> - thread_info is now located at the beginning of task_struct.
> - The 'cpu' field is now in task_struct, and only exists when
> CONFIG_SMP is active.
> - thread_info doesn't have anymore the 'task' field.
>
> This patch:
> - Removes all recopy of thread_info struct when the stack changes.
> - Changes the CURRENT_THREAD_INFO() macro to point to current.
> - Selects CONFIG_THREAD_INFO_IN_TASK.
> - Modifies raw_smp_processor_id() to get ->cpu from current without
> including linux/sched.h to avoid circular inclusion and without
> including asm/asm-offsets.h to avoid symbol names duplication
> between ASM constants and C constants.
> - Modifies klp_init_thread_info() to take a task_struct pointer
> argument.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
[...]
> +ifdef CONFIG_SMP
> +prepare: task_cpu_prepare
> +
> +task_cpu_prepare: prepare0
> + $(eval KBUILD_CFLAGS += -D_TASK_CPU=$(shell awk '{if ($$2 == "TI_CPU") print $$3;}' include/generated/asm-offsets.h))
> +endif
[...]
> -#define raw_smp_processor_id() (current_thread_info()->cpu)
> +/*
> + * This is particularly ugly: it appears we can't actually get the definition
> + * of task_struct here, but we need access to the CPU this task is running on.
> + * Instead of using task_struct we're using _TASK_CPU which is extracted from
> + * asm-offsets.h by kbuild to get the current processor ID.
> + *
> + * This also needs to be safeguarded when building asm-offsets.s because at
> + * that time _TASK_CPU is not defined yet. It could have been guarded by
> + * _TASK_CPU itself, but we want the build to fail if _TASK_CPU is missing
> + * when building something else than asm-offsets.s
> + */
> +#ifdef GENERATING_ASM_OFFSETS
> +#define raw_smp_processor_id() (0)
> +#else
> +#define raw_smp_processor_id() (*(unsigned int *)((void *)current + _TASK_CPU))
> +#endif
> #define hard_smp_processor_id() (smp_hw_index[smp_processor_id()])
On arm64 we have the per-cpu offset in a CPU register (TPIDR_EL1), so we
can do:
DEFINE_PER_CPU_READ_MOSTLY(int, cpu_number);
#define raw_smp_processor_id() (*raw_cpu_ptr(&cpu_number))
... but I guess that's not possible on PPC for some reason?
I think I asked that before, but I couldn't find the thread.
Otherwise, this all looks sound to me, but I don't know much about PPC.
Thanks,
Mark.
next prev parent reply other threads:[~2019-01-24 17:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 16:19 [PATCH v14 00/12] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 01/12] powerpc/32: Fix CONFIG_VIRT_CPU_ACCOUNTING_NATIVE for 40x/booke Christophe Leroy
2019-01-30 8:08 ` Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address Christophe Leroy
2019-01-24 16:51 ` Mark Rutland
2019-01-24 17:25 ` Mike Rapoport
2019-01-24 17:28 ` Mark Rutland
2019-01-24 16:19 ` [PATCH v14 03/12] book3s/64: avoid circular header inclusion in mmu-hash.h Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 04/12] powerpc: Only use task_struct 'cpu' field on SMP Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 05/12] powerpc: prep stack walkers for THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 17:04 ` Mark Rutland
2019-01-24 16:19 ` [PATCH v14 06/12] powerpc: Prepare for moving thread_info into task_struct Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 17:18 ` Mark Rutland [this message]
2019-01-24 16:19 ` [PATCH v14 08/12] powerpc: regain entire stack space Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 09/12] powerpc: 'current_set' is now a table of task_struct pointers Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 10/12] powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 11/12] powerpc/64: Remove CURRENT_THREAD_INFO Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 12/12] powerpc: clean stack pointers naming Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190124171814.GD5531@lakrids.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=rppt@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®