* Re: remove the last set_fs() in common code, and remove it for x86 and powerpc
From: Christophe Leroy @ 2020-08-18 17:46 UTC (permalink / raw)
To: Christoph Hellwig, Al Viro, Michael Ellerman, x86
Cc: linux-fsdevel, linux-arch, linuxppc-dev, Kees Cook, linux-kernel
In-Reply-To: <20200817073212.830069-1-hch@lst.de>
Le 17/08/2020 à 09:32, Christoph Hellwig a écrit :
> Hi all,
>
> this series removes the last set_fs() used to force a kernel address
> space for the uaccess code in the kernel read/write/splice code, and then
> stops implementing the address space overrides entirely for x86 and
> powerpc.
>
> The file system part has been posted a few times, and the read/write side
> has been pretty much unchanced. For splice this series drops the
> conversion of the seq_file and sysctl code to the iter ops, and thus loses
> the splice support for them. The reasons for that is that it caused a lot
> of churn for not much use - splice for these small files really isn't much
> of a win, even if existing userspace uses it. All callers I found do the
> proper fallback, but if this turns out to be an issue the conversion can
> be resurrected.
I like this series.
I gave it a go on my powerpc mpc832x. I tested it on top of my newest
series that reworks the 32 bits signal handlers (see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=196278)
with the microbenchmark test used is that series.
With KUAP activated, on top of signal32 rework, performance is boosted
as system time for the microbenchmark goes from 1.73s down to 1.56s,
that is 10% quicker
Surprisingly, with the kernel as is today without my signal's series,
your series degrades performance slightly (from 2.55s to 2.64s ie 3.5%
slower).
I also observe, in both cases, a degradation on
dd if=/dev/zero of=/dev/null count=1M
Without your series, it runs in 5.29 seconds.
With your series, it runs in 5.82 seconds, that is 10% more time.
Christophe
>
> Besides x86 and powerpc I plan to eventually convert all other
> architectures, although this will be a slow process, starting with the
> easier ones once the infrastructure is merged. The process to convert
> architectures is roughtly:
>
> - ensure there is no set_fs(KERNEL_DS) left in arch specific code
> - implement __get_kernel_nofault and __put_kernel_nofault
> - remove the arch specific address limitation functionality
>
> Diffstat:
> arch/Kconfig | 3
> arch/alpha/Kconfig | 1
> arch/arc/Kconfig | 1
> arch/arm/Kconfig | 1
> arch/arm64/Kconfig | 1
> arch/c6x/Kconfig | 1
> arch/csky/Kconfig | 1
> arch/h8300/Kconfig | 1
> arch/hexagon/Kconfig | 1
> arch/ia64/Kconfig | 1
> arch/m68k/Kconfig | 1
> arch/microblaze/Kconfig | 1
> arch/mips/Kconfig | 1
> arch/nds32/Kconfig | 1
> arch/nios2/Kconfig | 1
> arch/openrisc/Kconfig | 1
> arch/parisc/Kconfig | 1
> arch/powerpc/include/asm/processor.h | 7 -
> arch/powerpc/include/asm/thread_info.h | 5 -
> arch/powerpc/include/asm/uaccess.h | 78 ++++++++-----------
> arch/powerpc/kernel/signal.c | 3
> arch/powerpc/lib/sstep.c | 6 -
> arch/riscv/Kconfig | 1
> arch/s390/Kconfig | 1
> arch/sh/Kconfig | 1
> arch/sparc/Kconfig | 1
> arch/um/Kconfig | 1
> arch/x86/ia32/ia32_aout.c | 1
> arch/x86/include/asm/page_32_types.h | 11 ++
> arch/x86/include/asm/page_64_types.h | 38 +++++++++
> arch/x86/include/asm/processor.h | 60 ---------------
> arch/x86/include/asm/thread_info.h | 2
> arch/x86/include/asm/uaccess.h | 26 ------
> arch/x86/kernel/asm-offsets.c | 3
> arch/x86/lib/getuser.S | 28 ++++---
> arch/x86/lib/putuser.S | 21 +++--
> arch/xtensa/Kconfig | 1
> drivers/char/mem.c | 16 ----
> drivers/misc/lkdtm/bugs.c | 2
> drivers/misc/lkdtm/core.c | 4 +
> drivers/misc/lkdtm/usercopy.c | 2
> fs/read_write.c | 69 ++++++++++-------
> fs/splice.c | 130 +++------------------------------
> include/linux/fs.h | 2
> include/linux/uaccess.h | 18 ++++
> lib/test_bitmap.c | 10 ++
> 46 files changed, 235 insertions(+), 332 deletions(-)
>
^ permalink raw reply
* Re: remove the last set_fs() in common code, and remove it for x86 and powerpc
From: Christoph Hellwig @ 2020-08-18 18:05 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, Kees Cook, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <319d15b1-cb4a-a7b4-3082-12bb30eb5143@csgroup.eu>
On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
> I gave it a go on my powerpc mpc832x. I tested it on top of my newest
> series that reworks the 32 bits signal handlers (see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=196278) with
> the microbenchmark test used is that series.
>
> With KUAP activated, on top of signal32 rework, performance is boosted as
> system time for the microbenchmark goes from 1.73s down to 1.56s, that is
> 10% quicker
>
> Surprisingly, with the kernel as is today without my signal's series, your
> series degrades performance slightly (from 2.55s to 2.64s ie 3.5% slower).
>
>
> I also observe, in both cases, a degradation on
>
> dd if=/dev/zero of=/dev/null count=1M
>
> Without your series, it runs in 5.29 seconds.
> With your series, it runs in 5.82 seconds, that is 10% more time.
That's pretty strage, I wonder if some kernel text cache line
effects come into play here?
The kernel access side is only used in slow path code, so it should
not make a difference, and the uaccess code is simplified and should be
(marginally) faster.
Btw, was this with the __{get,put}_user_allowed cockup that you noticed
fixed?
^ permalink raw reply
* Re: remove the last set_fs() in common code, and remove it for x86 and powerpc
From: Christophe Leroy @ 2020-08-18 18:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Kees Cook, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200818180555.GA29185@lst.de>
Le 18/08/2020 à 20:05, Christoph Hellwig a écrit :
> On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
>> I gave it a go on my powerpc mpc832x. I tested it on top of my newest
>> series that reworks the 32 bits signal handlers (see
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=196278) with
>> the microbenchmark test used is that series.
>>
>> With KUAP activated, on top of signal32 rework, performance is boosted as
>> system time for the microbenchmark goes from 1.73s down to 1.56s, that is
>> 10% quicker
>>
>> Surprisingly, with the kernel as is today without my signal's series, your
>> series degrades performance slightly (from 2.55s to 2.64s ie 3.5% slower).
>>
>>
>> I also observe, in both cases, a degradation on
>>
>> dd if=/dev/zero of=/dev/null count=1M
>>
>> Without your series, it runs in 5.29 seconds.
>> With your series, it runs in 5.82 seconds, that is 10% more time.
>
> That's pretty strage, I wonder if some kernel text cache line
> effects come into play here?
>
> The kernel access side is only used in slow path code, so it should
> not make a difference, and the uaccess code is simplified and should be
> (marginally) faster.
>
> Btw, was this with the __{get,put}_user_allowed cockup that you noticed
> fixed?
>
Yes it is with the __get_user_size() replaced by __get_user_size_allowed().
Christophe
^ permalink raw reply
* Re: [PATCH 07/11] x86: move PAGE_OFFSET, TASK_SIZE & friends to page_{32,64}_types.h
From: Kees Cook @ 2020-08-18 19:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-8-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:08AM +0200, Christoph Hellwig wrote:
> At least for 64-bit this moves them closer to some of the defines
> they are based on, and it prepares for using the TASK_SIZE_MAX
> definition from assembly.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 06/11] lkdtm: disable set_fs-based tests for !CONFIG_SET_FS
From: Kees Cook @ 2020-08-18 19:32 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-7-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:07AM +0200, Christoph Hellwig wrote:
> Once we can't manipulate the address limit, we also can't test what
> happens when the manipulation is abused.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/misc/lkdtm/bugs.c | 2 ++
> drivers/misc/lkdtm/core.c | 4 ++++
> drivers/misc/lkdtm/usercopy.c | 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
> index 4dfbfd51bdf774..66f1800b1cb82d 100644
> --- a/drivers/misc/lkdtm/bugs.c
> +++ b/drivers/misc/lkdtm/bugs.c
> @@ -312,6 +312,7 @@ void lkdtm_CORRUPT_LIST_DEL(void)
> pr_err("list_del() corruption not detected!\n");
> }
>
> +#ifdef CONFIG_SET_FS
> /* Test if unbalanced set_fs(KERNEL_DS)/set_fs(USER_DS) check exists. */
> void lkdtm_CORRUPT_USER_DS(void)
> {
> @@ -321,6 +322,7 @@ void lkdtm_CORRUPT_USER_DS(void)
> /* Make sure we do not keep running with a KERNEL_DS! */
> force_sig(SIGKILL);
> }
> +#endif
Please let the test defined, but it should XFAIL with a message about
the CONFIG (see similar ifdefs in lkdtm).
> /* Test that VMAP_STACK is actually allocating with a leading guard page */
> void lkdtm_STACK_GUARD_PAGE_LEADING(void)
> diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
> index a5e344df916632..aae08b33a7ee2a 100644
> --- a/drivers/misc/lkdtm/core.c
> +++ b/drivers/misc/lkdtm/core.c
> @@ -112,7 +112,9 @@ static const struct crashtype crashtypes[] = {
> CRASHTYPE(CORRUPT_STACK_STRONG),
> CRASHTYPE(CORRUPT_LIST_ADD),
> CRASHTYPE(CORRUPT_LIST_DEL),
> +#ifdef CONFIG_SET_FS
> CRASHTYPE(CORRUPT_USER_DS),
> +#endif
> CRASHTYPE(STACK_GUARD_PAGE_LEADING),
> CRASHTYPE(STACK_GUARD_PAGE_TRAILING),
> CRASHTYPE(UNSET_SMEP),
> @@ -172,7 +174,9 @@ static const struct crashtype crashtypes[] = {
> CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
> CRASHTYPE(USERCOPY_STACK_BEYOND),
> CRASHTYPE(USERCOPY_KERNEL),
> +#ifdef CONFIG_SET_FS
> CRASHTYPE(USERCOPY_KERNEL_DS),
> +#endif
> CRASHTYPE(STACKLEAK_ERASING),
> CRASHTYPE(CFI_FORWARD_PROTO),
Then none of these are needed.
> #ifdef CONFIG_X86_32
Hmpf, this ifdef was missed in ae56942c1474 ("lkdtm: Make arch-specific
tests always available"). I will fix that.
> diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
> index b833367a45d053..4b632fe79ab6bb 100644
> --- a/drivers/misc/lkdtm/usercopy.c
> +++ b/drivers/misc/lkdtm/usercopy.c
> @@ -325,6 +325,7 @@ void lkdtm_USERCOPY_KERNEL(void)
> vm_munmap(user_addr, PAGE_SIZE);
> }
>
> +#ifdef CONFIG_SET_FS
> void lkdtm_USERCOPY_KERNEL_DS(void)
> {
> char __user *user_ptr =
> @@ -339,6 +340,7 @@ void lkdtm_USERCOPY_KERNEL_DS(void)
> pr_err("copy_to_user() to noncanonical address succeeded!?\n");
> set_fs(old_fs);
> }
> +#endif
(Same here, please.)
>
> void __init lkdtm_usercopy_init(void)
> {
> --
> 2.28.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 01/11] mem: remove duplicate ops for /dev/zero and /dev/null
From: Kees Cook @ 2020-08-18 19:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-2-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:02AM +0200, Christoph Hellwig wrote:
> There is no good reason to implement both the traditional ->read and
> ->write as well as the iter based ops. So implement just the iter
> based ones.
>
> Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 02/11] fs: don't allow kernel reads and writes without iter ops
From: Kees Cook @ 2020-08-18 19:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-3-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:03AM +0200, Christoph Hellwig wrote:
> Don't allow calling ->read or ->write with set_fs as a preparation for
> killing off set_fs. All the instances that we use kernel_read/write on
> are using the iter ops already.
>
> If a file has both the regular ->read/->write methods and the iter
> variants those could have different semantics for messed up enough
> drivers. Also fails the kernel access to them in that case.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Do not initiate shutdown when system is running on UPS
From: Tyrel Datwyler @ 2020-08-18 19:35 UTC (permalink / raw)
To: Vasant Hegde, linuxppc-dev; +Cc: stable
In-Reply-To: <20200818105424.234108-1-hegdevasant@linux.vnet.ibm.com>
On 8/18/20 3:54 AM, Vasant Hegde wrote:
> As per PAPR specification whenever system is running on UPS we have to
> wait for predefined time (default 10mins) before initiating shutdown.
The wording in PAPR seems a little unclear. It states for an
EPOW_SYSTEM_SHUTDOWN action code that an EPOW error should be logged followed by
scheduling a shutdown to begin after an OS defined delay interval (with 10
minutes the suggested default).
However, the modifier code descriptions seems to imply that a normal shutdown is
the only one that should happen with no additional delay.
For EPOW sensor value = 3 (EPOW_SYSTEM_SHUTDOWN)
0x01 = Normal system shutdown with no additional delay
0x02 = Loss of utility power, system is running on UPS/Battery
0x03 = Loss of system critical functions, system should be shutdown
0x04 = Ambient temperature too high
For 0x03-0x04 we also do an orderly_poweroff().
Not sure if it really matters, but I was curious and this is just what I gleaned
from glancing at PAPR.
-Tyrel
>
> We have user space tool (rtas_errd) to monitor for EPOW events and
> initiate shutdown after predefined time. Hence do not initiate shutdown
> whenever we get EPOW_SHUTDOWN_ON_UPS event.
>
> Fixes: 79872e35 (powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown)
> Cc: stable@vger.kernel.org # v4.0+
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/ras.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
> index f3736fcd98fc..13c86a292c6d 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -184,7 +184,6 @@ static void handle_system_shutdown(char event_modifier)
> case EPOW_SHUTDOWN_ON_UPS:
> pr_emerg("Loss of system power detected. System is running on"
> " UPS/battery. Check RTAS error log for details\n");
> - orderly_poweroff(true);
> break;
>
> case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
>
^ permalink raw reply
* Re: [PATCH 03/11] fs: don't allow splice read/write without explicit ops
From: Kees Cook @ 2020-08-18 19:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-4-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:04AM +0200, Christoph Hellwig wrote:
> default_file_splice_write is the last piece of generic code that uses
> set_fs to make the uaccess routines operate on kernel pointers. It
> implements a "fallback loop" for splicing from files that do not actually
> provide a proper splice_read method. The usual file systems and other
> high bandwith instances all provide a ->splice_read, so this just removes
> support for various device drivers and procfs/debugfs files. If splice
> support for any of those turns out to be important it can be added back
> by switching them to the iter ops and using generic_file_splice_read.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
This seems a bit disruptive? I feel like this is going to make fuzzers
really noisy (e.g. trinity likes to splice random stuff out of /sys and
/proc).
Conceptually, though:
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 04/11] uaccess: add infrastructure for kernel builds with set_fs()
From: Kees Cook @ 2020-08-18 19:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-5-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:05AM +0200, Christoph Hellwig wrote:
> Add a CONFIG_SET_FS option that is selected by architecturess that
> implement set_fs, which is all of them initially. If the option is not
> set stubs for routines related to overriding the address space are
> provided so that architectures can start to opt out of providing set_fs.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 05/11] test_bitmap: skip user bitmap tests for !CONFIG_SET_FS
From: Kees Cook @ 2020-08-18 19:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-6-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:06AM +0200, Christoph Hellwig wrote:
> We can't run the tests for userspace bitmap parsing if set_fs() doesn't
> exist.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code
From: Kees Cook @ 2020-08-18 19:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-9-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:09AM +0200, Christoph Hellwig wrote:
> For 64-bit the only hing missing was a strategic _AC, and for 32-bit we
typo: thing
> need to use __PAGE_OFFSET instead of PAGE_OFFSET in the TASK_SIZE
> definition to escape the explicit unsigned long cast. This just works
> because __PAGE_OFFSET is defined using _AC itself and thus never needs
> the cast anyway.
Shouldn't this be folded into the prior patch so there's no bisection
problem?
-Kees
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/x86/include/asm/page_32_types.h | 4 ++--
> arch/x86/include/asm/page_64_types.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
> index 26236925fb2c36..f462895a33e452 100644
> --- a/arch/x86/include/asm/page_32_types.h
> +++ b/arch/x86/include/asm/page_32_types.h
> @@ -44,8 +44,8 @@
> /*
> * User space process size: 3GB (default).
> */
> -#define IA32_PAGE_OFFSET PAGE_OFFSET
> -#define TASK_SIZE PAGE_OFFSET
> +#define IA32_PAGE_OFFSET __PAGE_OFFSET
> +#define TASK_SIZE __PAGE_OFFSET
> #define TASK_SIZE_LOW TASK_SIZE
> #define TASK_SIZE_MAX TASK_SIZE
> #define DEFAULT_MAP_WINDOW TASK_SIZE
> diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
> index 996595c9897e0a..838515daf87b36 100644
> --- a/arch/x86/include/asm/page_64_types.h
> +++ b/arch/x86/include/asm/page_64_types.h
> @@ -76,7 +76,7 @@
> *
> * With page table isolation enabled, we map the LDT in ... [stay tuned]
> */
> -#define TASK_SIZE_MAX ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
> +#define TASK_SIZE_MAX ((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
>
> #define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
>
> --
> 2.28.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 09/11] x86: remove address space overrides using set_fs()
From: Kees Cook @ 2020-08-18 19:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200817073212.830069-10-hch@lst.de>
On Mon, Aug 17, 2020 at 09:32:10AM +0200, Christoph Hellwig wrote:
> Stop providing the possibility to override the address space using
> set_fs() now that there is no need for that any more. To properly
> handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> x86 a new alternative is introduced, which just like the one in
> entry_64.S has to use the hardcoded virtual address bits to escape
> the fact that TASK_SIZE_MAX isn't actually a constant when 5-level
> page tables are enabled.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Awesome. :)
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
From: Thiago Jung Bauermann @ 2020-08-18 19:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Konrad Rzeszutek Wilk, linuxppc-dev, Ram Pai, linux-kernel, iommu,
Satheesh Rajendran, Robin Murphy, Marek Szyprowski
In-Reply-To: <20200818065911.GA2324@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Mon, Aug 17, 2020 at 06:46:58PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be in low addresses since the
>> hypervisor doesn't have any addressing limitation.
>>
>> This solves a SWIOTLB initialization problem we are seeing in secure guests
>> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
>> memory, which leaves no space for SWIOTLB in low addresses.
>>
>> To do this, we use mostly the same code as swiotlb_init(), but allocate the
>> buffer using memblock_alloc() instead of memblock_alloc_low().
>>
>> We also need to add swiotlb_set_no_iotlb_memory() in order to set the
>> no_iotlb_memory flag if initialization fails.
>
> Do you really need the helper? As far as I can tell the secure guests
> very much rely on swiotlb for all I/O, so you might as well panic if
> you fail to allocate it.
That is true. Ok, I will do that.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 03/11] fs: don't allow splice read/write without explicit ops
From: Christoph Hellwig @ 2020-08-18 19:54 UTC (permalink / raw)
To: Kees Cook
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <202008181239.E51B80265@keescook>
On Tue, Aug 18, 2020 at 12:39:34PM -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 09:32:04AM +0200, Christoph Hellwig wrote:
> > default_file_splice_write is the last piece of generic code that uses
> > set_fs to make the uaccess routines operate on kernel pointers. It
> > implements a "fallback loop" for splicing from files that do not actually
> > provide a proper splice_read method. The usual file systems and other
> > high bandwith instances all provide a ->splice_read, so this just removes
> > support for various device drivers and procfs/debugfs files. If splice
> > support for any of those turns out to be important it can be added back
> > by switching them to the iter ops and using generic_file_splice_read.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> This seems a bit disruptive? I feel like this is going to make fuzzers
> really noisy (e.g. trinity likes to splice random stuff out of /sys and
> /proc).
Noisy in the sence of triggering the pr_debug or because they can't
handle -EINVAL?
^ permalink raw reply
* Re: [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code
From: Christoph Hellwig @ 2020-08-18 19:55 UTC (permalink / raw)
To: Kees Cook
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <202008181244.BBDA7DAB@keescook>
On Tue, Aug 18, 2020 at 12:44:49PM -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 09:32:09AM +0200, Christoph Hellwig wrote:
> > For 64-bit the only hing missing was a strategic _AC, and for 32-bit we
>
> typo: thing
>
> > need to use __PAGE_OFFSET instead of PAGE_OFFSET in the TASK_SIZE
> > definition to escape the explicit unsigned long cast. This just works
> > because __PAGE_OFFSET is defined using _AC itself and thus never needs
> > the cast anyway.
>
> Shouldn't this be folded into the prior patch so there's no bisection
> problem?
I didn't see a problem bisecting, do you have something particular in
mind?
^ permalink raw reply
* Re: [PATCH 03/11] fs: don't allow splice read/write without explicit ops
From: Kees Cook @ 2020-08-18 19:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200818195446.GA32691@lst.de>
On Tue, Aug 18, 2020 at 09:54:46PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:39:34PM -0700, Kees Cook wrote:
> > On Mon, Aug 17, 2020 at 09:32:04AM +0200, Christoph Hellwig wrote:
> > > default_file_splice_write is the last piece of generic code that uses
> > > set_fs to make the uaccess routines operate on kernel pointers. It
> > > implements a "fallback loop" for splicing from files that do not actually
> > > provide a proper splice_read method. The usual file systems and other
> > > high bandwith instances all provide a ->splice_read, so this just removes
> > > support for various device drivers and procfs/debugfs files. If splice
> > > support for any of those turns out to be important it can be added back
> > > by switching them to the iter ops and using generic_file_splice_read.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > This seems a bit disruptive? I feel like this is going to make fuzzers
> > really noisy (e.g. trinity likes to splice random stuff out of /sys and
> > /proc).
>
> Noisy in the sence of triggering the pr_debug or because they can't
> handle -EINVAL?
Well, maybe both? I doubt much _expects_ to be using splice, so I'm fine
with that, but it seems weird not to have a fall-back, especially if
something would like to splice a file out of there. But, I'm not opposed
to the change, it just seems like it might cause pain down the road.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code
From: Kees Cook @ 2020-08-18 19:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200818195539.GB32691@lst.de>
On Tue, Aug 18, 2020 at 09:55:39PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:44:49PM -0700, Kees Cook wrote:
> > On Mon, Aug 17, 2020 at 09:32:09AM +0200, Christoph Hellwig wrote:
> > > For 64-bit the only hing missing was a strategic _AC, and for 32-bit we
> >
> > typo: thing
> >
> > > need to use __PAGE_OFFSET instead of PAGE_OFFSET in the TASK_SIZE
> > > definition to escape the explicit unsigned long cast. This just works
> > > because __PAGE_OFFSET is defined using _AC itself and thus never needs
> > > the cast anyway.
> >
> > Shouldn't this be folded into the prior patch so there's no bisection
> > problem?
>
> I didn't see a problem bisecting, do you have something particular in
> mind?
Oh, I misunderstood this patch to be a fix for compilation. Is this just
a correctness fix?
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code
From: Christoph Hellwig @ 2020-08-18 20:00 UTC (permalink / raw)
To: Kees Cook
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <202008181258.CEC4B8B3@keescook>
On Tue, Aug 18, 2020 at 12:59:05PM -0700, Kees Cook wrote:
> > I didn't see a problem bisecting, do you have something particular in
> > mind?
>
> Oh, I misunderstood this patch to be a fix for compilation. Is this just
> a correctness fix?
It prepares for using the definition from assembly, which is done in
the next patch.
^ permalink raw reply
* Re: [PATCH 03/11] fs: don't allow splice read/write without explicit ops
From: Christoph Hellwig @ 2020-08-18 20:07 UTC (permalink / raw)
To: Kees Cook
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <202008181256.CABD56782@keescook>
On Tue, Aug 18, 2020 at 12:58:07PM -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 09:54:46PM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 18, 2020 at 12:39:34PM -0700, Kees Cook wrote:
> > > On Mon, Aug 17, 2020 at 09:32:04AM +0200, Christoph Hellwig wrote:
> > > > default_file_splice_write is the last piece of generic code that uses
> > > > set_fs to make the uaccess routines operate on kernel pointers. It
> > > > implements a "fallback loop" for splicing from files that do not actually
> > > > provide a proper splice_read method. The usual file systems and other
> > > > high bandwith instances all provide a ->splice_read, so this just removes
> > > > support for various device drivers and procfs/debugfs files. If splice
> > > > support for any of those turns out to be important it can be added back
> > > > by switching them to the iter ops and using generic_file_splice_read.
> > > >
> > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > >
> > > This seems a bit disruptive? I feel like this is going to make fuzzers
> > > really noisy (e.g. trinity likes to splice random stuff out of /sys and
> > > /proc).
> >
> > Noisy in the sence of triggering the pr_debug or because they can't
> > handle -EINVAL?
>
> Well, maybe both? I doubt much _expects_ to be using splice, so I'm fine
> with that, but it seems weird not to have a fall-back, especially if
> something would like to splice a file out of there. But, I'm not opposed
> to the change, it just seems like it might cause pain down the road.
The problem is that without pretending a buffer is in user space when
it actually isn't, we can't have a generic fallback. So we'll have to
have specific support - I wrote generic support for seq_file, and
willy did for /proc/sys, but at least the first caused a few problems
and a fair amount of churn, so I'd rather see first if we can get
away without it.
>
> --
> Kees Cook
---end quoted text---
^ permalink raw reply
* Re: [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code
From: Kees Cook @ 2020-08-18 20:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <20200818200016.GA681@lst.de>
On Tue, Aug 18, 2020 at 10:00:16PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:59:05PM -0700, Kees Cook wrote:
> > > I didn't see a problem bisecting, do you have something particular in
> > > mind?
> >
> > Oh, I misunderstood this patch to be a fix for compilation. Is this just
> > a correctness fix?
>
> It prepares for using the definition from assembly, which is done in
> the next patch.
Ah! Okay; thanks.
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: remove PROT_SAO support
From: Shawn Anastasio @ 2020-08-18 20:59 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1597733955.vlt37n2lw9.astroid@bobo.none>
On 8/18/20 2:11 AM, Nicholas Piggin wrote> Very reasonable point.
>
> The problem we're trying to get a handle on is live partition migration
> where a running guest might be using SAO then get migrated to a P10. I
> don't think we have a good way to handle this case. Potentially the
> hypervisor could revoke the page tables if the guest is running in hash
> mode and the guest kernel could be taught about that and sigbus the
> process, but in radix the guest controls those page tables and the SAO
> state and I don't think there's a way to cause it to take a fault.
>
> I also don't know what the proprietary hypervisor does here.
>
> We could add it back, default to n, or make it bare metal only, or
> somehow try to block live migration to a later CPU without the faciliy.
> I wouldn't be against that.
Admittedly I'm not too familiar with the specifics of live migration
or guest memory management, but restoring the functionality and adding
a way to prevent migration of SAO-using guests seems like a reasonable
choice to me. Would this be done with help from the guest using some
sort of infrastructure to signal to the hypervisor that SAO is in use,
or entirely on the hypervisor by e.g. scanning the through the process
table for SAO pages?
> It would be very interesting to know how it performs in such a "real"
> situation. I don't know how well POWER9 has optimised it -- it's
> possible that it's not much better than putting lwsync after every load
> or store.
This is definitely worth investigating in depth. That said, even if the
performance on P9 isn't super great, I think the feature could still be
useful, since it would offer more granularity than the sledgehammer
approach of emitting lwsync everywhere.
I'd be happy to put in some of the work required to get this to a point
where it can be reintroduced without breaking guest migration - I'd just
need some pointers on getting started with whatever approach is decided on.
Thanks,
Shawn
^ permalink raw reply
* [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
From: Thiago Jung Bauermann @ 2020-08-18 22:11 UTC (permalink / raw)
To: iommu
Cc: Konrad Rzeszutek Wilk, linuxppc-dev, Ram Pai, linux-kernel,
Satheesh Rajendran, Robin Murphy, Christoph Hellwig,
Thiago Jung Bauermann, Marek Szyprowski
POWER secure guests (i.e., guests which use the Protection Execution
Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
they don't need the SWIOTLB memory to be in low addresses since the
hypervisor doesn't have any addressing limitation.
This solves a SWIOTLB initialization problem we are seeing in secure guests
with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
memory, which leaves no space for SWIOTLB in low addresses.
To do this, we use mostly the same code as swiotlb_init(), but allocate the
buffer using memblock_alloc() instead of memblock_alloc_low().
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/include/asm/svm.h | 4 ++++
arch/powerpc/mm/mem.c | 6 +++++-
arch/powerpc/platforms/pseries/svm.c | 26 ++++++++++++++++++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
Changes from v2:
- Panic if unable to allocate buffer, as suggested by Christoph.
Changes from v1:
- Open-code swiotlb_init() in arch-specific code, as suggested by
Christoph.
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
index 85580b30aba4..7546402d796a 100644
--- a/arch/powerpc/include/asm/svm.h
+++ b/arch/powerpc/include/asm/svm.h
@@ -15,6 +15,8 @@ static inline bool is_secure_guest(void)
return mfmsr() & MSR_S;
}
+void __init svm_swiotlb_init(void);
+
void dtl_cache_ctor(void *addr);
#define get_dtl_cache_ctor() (is_secure_guest() ? dtl_cache_ctor : NULL)
@@ -25,6 +27,8 @@ static inline bool is_secure_guest(void)
return false;
}
+static inline void svm_swiotlb_init(void) {}
+
#define get_dtl_cache_ctor() NULL
#endif /* CONFIG_PPC_SVM */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c2c11eb8dcfc..0f21bcb16405 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -50,6 +50,7 @@
#include <asm/swiotlb.h>
#include <asm/rtas.h>
#include <asm/kasan.h>
+#include <asm/svm.h>
#include <mm/mmu_decl.h>
@@ -290,7 +291,10 @@ void __init mem_init(void)
* back to to-down.
*/
memblock_set_bottom_up(true);
- swiotlb_init(0);
+ if (is_secure_guest())
+ svm_swiotlb_init();
+ else
+ swiotlb_init(0);
#endif
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
diff --git a/arch/powerpc/platforms/pseries/svm.c b/arch/powerpc/platforms/pseries/svm.c
index 40c0637203d5..81085eb8f225 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -7,6 +7,7 @@
*/
#include <linux/mm.h>
+#include <linux/memblock.h>
#include <asm/machdep.h>
#include <asm/svm.h>
#include <asm/swiotlb.h>
@@ -34,6 +35,31 @@ static int __init init_svm(void)
}
machine_early_initcall(pseries, init_svm);
+/*
+ * Initialize SWIOTLB. Essentially the same as swiotlb_init(), except that it
+ * can allocate the buffer anywhere in memory. Since the hypervisor doesn't have
+ * any addressing limitation, we don't need to allocate it in low addresses.
+ */
+void __init svm_swiotlb_init(void)
+{
+ unsigned char *vstart;
+ unsigned long bytes, io_tlb_nslabs;
+
+ io_tlb_nslabs = (swiotlb_size_or_default() >> IO_TLB_SHIFT);
+ io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
+
+ bytes = io_tlb_nslabs << IO_TLB_SHIFT;
+
+ vstart = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
+ if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, false))
+ return;
+
+ if (io_tlb_start)
+ memblock_free_early(io_tlb_start,
+ PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
+ panic("SVM: Cannot allocate SWIOTLB buffer");
+}
+
int set_memory_encrypted(unsigned long addr, int numpages)
{
if (!PAGE_ALIGNED(addr))
^ permalink raw reply related
* Re: [PATCH v3 10/17] memblock: reduce number of parameters in for_each_mem_range()
From: Miguel Ojeda @ 2020-08-18 22:18 UTC (permalink / raw)
To: Mike Rapoport
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Russell King,
Mike Rapoport, clang-built-linux, Ingo Molnar, Linux ARM,
Catalin Marinas, uclinux-h8-devel, linux-xtensa, openrisc,
Borislav Petkov, Andy Lutomirski, Paul Walmsley, Stafford Horne,
Hari Bathini, Daniel Axtens, Michal Simek, Thomas Bogendoerfer,
Yoshinori Sato, Linux-MM, linux-kernel, iommu, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200818151634.14343-11-rppt@kernel.org>
On Tue, Aug 18, 2020 at 5:19 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> .clang-format | 2 ++
For the .clang-format bit:
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cheers,
Miguel
^ permalink raw reply
* [Bug 208957] New: 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);
From: bugzilla-daemon @ 2020-08-18 22:32 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=208957
Bug ID: 208957
Summary: 5.9-rc1 fails to build for a PowerMac G5:
.../book3s64/hash_utils.c:1119:21: error:
‘default_uamor’ undeclared (first use in this
function) 1119 | mtspr(SPRN_UAMOR, default_uamor);
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.9-rc1
Hardware: PPC-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-64
Assignee: platform_ppc-64@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: No
Created attachment 292021
--> https://bugzilla.kernel.org/attachment.cgi?id=292021&action=edit
kernel .config (kernel 5.9-rc1, PowerMac G5 11,2)
[...]
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC arch/powerpc/mm/book3s64/hash_utils.o
In file included from ./arch/powerpc/include/asm/processor.h:9,
from ./arch/powerpc/include/asm/thread_info.h:40,
from ./include/linux/thread_info.h:38,
from ./include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:51,
from arch/powerpc/mm/book3s64/hash_utils.c:21:
arch/powerpc/mm/book3s64/hash_utils.c: In function
‘hash__early_init_mmu_secondary’:
arch/powerpc/mm/book3s64/hash_utils.c:1119:21: error: ‘default_uamor’
undeclared (first use in this function)
1119 | mtspr(SPRN_UAMOR, default_uamor);
| ^~~~~~~~~~~~~
./arch/powerpc/include/asm/reg.h:1396:33: note: in definition of macro ‘mtspr’
1396 | : "r" ((unsigned long)(v)) \
| ^
arch/powerpc/mm/book3s64/hash_utils.c:1119:21: note: each undeclared identifier
is reported only once for each function it appears in
1119 | mtspr(SPRN_UAMOR, default_uamor);
| ^~~~~~~~~~~~~
./arch/powerpc/include/asm/reg.h:1396:33: note: in definition of macro ‘mtspr’
1396 | : "r" ((unsigned long)(v)) \
| ^
make[3]: *** [scripts/Makefile.build:283:
arch/powerpc/mm/book3s64/hash_utils.o] Error 1
make[2]: *** [scripts/Makefile.build:500: arch/powerpc/mm/book3s64] Error 2
make[1]: *** [scripts/Makefile.build:500: arch/powerpc/mm] Error 2
make: *** [Makefile:1789: arch/powerpc] Error 2
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox