* [PATCH] powerpc/ptrace: Remove duplicate check from pt_regs_check()
From: Denis Efremov @ 2021-03-05 11:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Denis Efremov
"offsetof(struct pt_regs, msr) == offsetof(struct user_pt_regs, msr)"
checked in pt_regs_check() twice in a row. Remove the second check.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
arch/powerpc/kernel/ptrace/ptrace.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c
index 4f3d4ff3728c..51801777906c 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -354,8 +354,6 @@ void __init pt_regs_check(void)
offsetof(struct user_pt_regs, nip));
BUILD_BUG_ON(offsetof(struct pt_regs, msr) !=
offsetof(struct user_pt_regs, msr));
- BUILD_BUG_ON(offsetof(struct pt_regs, msr) !=
- offsetof(struct user_pt_regs, msr));
BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
offsetof(struct user_pt_regs, orig_gpr3));
BUILD_BUG_ON(offsetof(struct pt_regs, ctr) !=
--
2.26.2
^ permalink raw reply related
* [PATCH] ASoC: fsl_asrc_dma: request dma channel from specific controller
From: Shengjiu Wang @ 2021-03-05 9:19 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel
Cc: linuxppc-dev, linux-kernel
From: Robin Gong <yibin.gong@nxp.com>
Request dma channel from specific dma controller instead of generic
dma controller list, otherwise, may get the wrong dma controller
if there are multi dma controllers such as i.MX8MP.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc_dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index 29f91cdecbc3..c313a26c8f95 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -141,6 +141,7 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
struct dma_slave_config config_fe, config_be;
enum asrc_pair_index index = pair->index;
struct device *dev = component->dev;
+ struct device_node *of_dma_node;
int stream = substream->stream;
struct imx_dma_data *tmp_data;
struct snd_soc_dpcm *dpcm;
@@ -231,8 +232,10 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
pair->dma_data.priority = tmp_data->priority;
dma_release_channel(tmp_chan);
+ of_dma_node = pair->dma_chan[!dir]->device->dev->of_node;
pair->dma_chan[dir] =
- dma_request_channel(mask, filter, &pair->dma_data);
+ __dma_request_channel(&mask, filter, &pair->dma_data,
+ of_dma_node);
pair->req_dma_chan = true;
} else {
pair->dma_chan[dir] = tmp_chan;
--
2.27.0
^ permalink raw reply related
* Re: [Freedreno] [PATCH 16/17] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG
From: Will Deacon @ 2021-03-05 10:00 UTC (permalink / raw)
To: Rob Clark
Cc: freedreno, Sai Prakash Ranjan, kvm, Joerg Roedel, linuxppc-dev,
dri-devel, Li Yang,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
netdev, David Woodhouse, linux-arm-msm, virtualization,
Robin Murphy, Christoph Hellwig,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAF6AEGtTs-=aO-Ntp0Qn6mYDSv4x0-q3y217QxU7kZ6H1b1fiQ@mail.gmail.com>
On Thu, Mar 04, 2021 at 03:11:08PM -0800, Rob Clark wrote:
> On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2021-03-01 08:42, Christoph Hellwig wrote:
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Moreso than the previous patch, where the feature is at least relatively
> > generic (note that there's a bunch of in-flight development around
> > DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
> > bloat the generic iommu_ops structure with private driver-specific
> > interfaces. The attribute interface is a great compromise for these
> > kinds of things, and you can easily add type-checked wrappers around it
> > for external callers (maybe even make the actual attributes internal
> > between the IOMMU core and drivers) if that's your concern.
>
> I suppose if this is *just* for the GPU we could move it into adreno_smmu_priv..
>
> But one thing I'm not sure about is whether
> IO_PGTABLE_QUIRK_ARM_OUTER_WBWA is something that other devices
> *should* be using as well, but just haven't gotten around to yet.
The intention is certainly that this would be a place to collate per-domain
pgtable quirks, so I'd prefer not to tie that to the GPU.
Will
^ permalink raw reply
* Re: [PATCH v3] powerpc/32: remove bogus ppc_select syscall
From: Arnd Bergmann @ 2021-03-05 10:06 UTC (permalink / raw)
To: Christophe Leroy
Cc: linuxppc-dev, Paul Mackerras, linux-kernel@vger.kernel.org
In-Reply-To: <f08ef2b6f339ba19987cfef4307a4dd26b2faf97.1614933479.git.christophe.leroy@csgroup.eu>
On Fri, Mar 5, 2021 at 9:40 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The ppc_select function was introduced in linux-2.3.48 in order to support
> code confusing the legacy select() calling convention with the standard one.
> Even 24 years ago, all correctly built code should not have done this and
> could have easily been phased out. Nothing that was compiled later should
> actually try to use the old_select interface, and it would have been broken
> already on all ppc64 kernels with the syscall emulation layer.
>
> This patch brings the 32 bit compat ABI and the native 32 bit ABI for
> powerpc into a consistent state, by removing support for both the
> old_select system call number and the handler for it.
The description still seems wrong, please drop all the nonsense I wrote
back then and explain what is actually going on.
This is what I can see from the linux-history tree:
- The original ppc32 port (linux-1.3.45) had a regular '__NR_select/sys_select'
syscall at #82 and an unusable '__NR__newselect/sys_panic' syscall at #142,
while i386 had the indirect '__NR_select/sys_oldselect' syscall at #82
and the regular '__NR__newselect/sys_select' version at #142. This was
rather confusing.
- linux-2.1.48 changed both #82 and #142 to the ppc_select() version that
tries to guess whether the x86 __NR_select/sys_oldselect() behavior or
the regular __NR__newselect/sys_select() behavior is used.
- linux-2.5.5 added ppc64 support, with a compat version of ppc_select()
on both #82 and #142 that would either use the __NR__newselect/sys_select
semantics or panic() when passed an invalud 'n'. The native ppc64
port started out with just __NR__newselect/sys_select() on #142
- linux-2.5.19 changed ppc64 compat mode to no longer panic(), making
both #82 and #142 behave like __NR__newselect/sys_select().
- glibc support for ppc32 gets merged during the linux-2.5 days, supporting
only #142 with the new behavior.
- linux-2.5.41 dropped support for #82 on ppc64 in compat mode but not
native ppc32.
- linux-2.6.14 merged the two architecture ports but kept the behavior
unchanged for both.
- linux-2.6.32 changed the native ppc32 #142 __NR__newselect to
behave the same as compat mode and no longer emulate the
x86 oldselect, but #82 remained unchanged.
So we have changed behavior multiple times in the past, and the
current state still theoretically allows running non-glibc binaries that
ran on kernels before 2.1.48 that used either the original powerpc
select or the i386 compatible oldselect semantics. Chances are that
those binaries are broken for some other reason now.
Arnd
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc: sstep: Fix load and update emulation
From: Naveen N. Rao @ 2021-03-04 1:06 UTC (permalink / raw)
To: Segher Boessenkool
Cc: ravi.bangoria, ananth, jniethe5, paulus, Sandipan Das,
linuxppc-dev, dja
In-Reply-To: <20210304154535.GS29191@gate.crashing.org>
On 2021/03/04 09:45AM, Segher Boessenkool wrote:
> On Wed, Mar 03, 2021 at 10:01:27PM +0530, Naveen N. Rao wrote:
> > On 2021/03/01 08:37PM, Segher Boessenkool wrote:
> > > > And, r6 always ends up with 0xaea. It changes with the value I put into
> > > > r6 though.
> > >
> > > That is exactly the behaviour specified for p8. 0aaa+0040=0aea.
> > >
> > > > Granted, this is all up in the air, but it does look like there is more
> > > > going on and the value isn't the EA or the value at the address.
> > >
> > > That *is* the EA. The EA is the address the insn does the access at.
> >
> > I'm probably missing something here. 0xaaa is the value I stored at an
> > offset of 64 bytes from the stack pointer (r1 is copied into r6). In the
> > ldu instruction above, the EA is 64(r6), which should translate to
> > r1+64. The data returned by the load would be 0xaaa, which should be
> > discarded per the description you provided above. So, I would expect to
> > see a 0xc0.. address in r6.
>
> Yes, I misread your code it seems.
>
> > In fact, this looks to be the behavior documented for P9:
> >
> > > > Power9 does:
> > > >
> > > > Load with Update Instructions (RA = 0)
> > > > EA is placed into R0.
> > > > Load with Update Instructions (RA = RT)
> > > > The storage operand addressed by EA is accessed. The
> > > > displacement
> > > > field is added to the data returned by the load and placed into
> > > > RT.
>
> Yup. So on what cpu did you test?
I tested this on two processors:
2.0 (pvr 004d 0200)
2.1 (pvr 004b 0201)
I guess the behavior changed some time during P8, but I don't have a P9
to test this on.
In any case, this souldn't matter too much for us as you rightly point
out:
>
> Either way, the kernel should not emulate any particular cpu here, I'd
> say, esp. since recent cpus do different things for this invalid form.
Ack.
Thanks!
- Naveen
^ permalink raw reply
* Re: [PATCH v3] powerpc/32: remove bogus ppc_select syscall
From: Christophe Leroy @ 2021-03-05 10:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel@vger.kernel.org
In-Reply-To: <CAK8P3a2b+u+8smkKWB-V2Non+nnZmNG4dNi6cGpM8weYuY5j6A@mail.gmail.com>
Le 05/03/2021 à 11:06, Arnd Bergmann a écrit :
> On Fri, Mar 5, 2021 at 9:40 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The ppc_select function was introduced in linux-2.3.48 in order to support
>> code confusing the legacy select() calling convention with the standard one.
>> Even 24 years ago, all correctly built code should not have done this and
>> could have easily been phased out. Nothing that was compiled later should
>> actually try to use the old_select interface, and it would have been broken
>> already on all ppc64 kernels with the syscall emulation layer.
>>
>> This patch brings the 32 bit compat ABI and the native 32 bit ABI for
>> powerpc into a consistent state, by removing support for both the
>> old_select system call number and the handler for it.
>
> The description still seems wrong, please drop all the nonsense I wrote
> back then and explain what is actually going on.
>
> This is what I can see from the linux-history tree:
>
> - The original ppc32 port (linux-1.3.45) had a regular '__NR_select/sys_select'
> syscall at #82 and an unusable '__NR__newselect/sys_panic' syscall at #142,
> while i386 had the indirect '__NR_select/sys_oldselect' syscall at #82
> and the regular '__NR__newselect/sys_select' version at #142. This was
> rather confusing.
>
> - linux-2.1.48 changed both #82 and #142 to the ppc_select() version that
> tries to guess whether the x86 __NR_select/sys_oldselect() behavior or
> the regular __NR__newselect/sys_select() behavior is used.
>
> - linux-2.5.5 added ppc64 support, with a compat version of ppc_select()
> on both #82 and #142 that would either use the __NR__newselect/sys_select
> semantics or panic() when passed an invalud 'n'. The native ppc64
> port started out with just __NR__newselect/sys_select() on #142
>
> - linux-2.5.19 changed ppc64 compat mode to no longer panic(), making
> both #82 and #142 behave like __NR__newselect/sys_select().
>
> - glibc support for ppc32 gets merged during the linux-2.5 days, supporting
> only #142 with the new behavior.
>
> - linux-2.5.41 dropped support for #82 on ppc64 in compat mode but not
> native ppc32.
>
> - linux-2.6.14 merged the two architecture ports but kept the behavior
> unchanged for both.
>
> - linux-2.6.32 changed the native ppc32 #142 __NR__newselect to
> behave the same as compat mode and no longer emulate the
> x86 oldselect, but #82 remained unchanged.
>
> So we have changed behavior multiple times in the past, and the
> current state still theoretically allows running non-glibc binaries that
> ran on kernels before 2.1.48 that used either the original powerpc
> select or the i386 compatible oldselect semantics. Chances are that
> those binaries are broken for some other reason now.
>
Whaou, nice archeology, thanks. Do you mind if I copy the history you established ?
In your commit, you said 2.3.48. Here in the history you say 2.1.48. Which one is correct ?
Regardless of whethere binaries are broken or not for other reason, is that worth expecting an
almost 25 yr old binary to run on future kernels ? If one is able to put the necessary effort to
port you hardware to the latest kernel, can't he really port the binary as well ?
Thanks
Christophe
^ permalink raw reply
* [PATCH] powerpc: Fix instruction encoding for lis in ppc_function_entry()
From: Naveen N. Rao @ 2021-03-04 2:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jiri Olsa
'lis r2,N' is 'addis r2,0,N' and the instruction encoding in the macro
LIS_R2 is incorrect (it currently maps to 'addis 0,r2,N'). Fix the same.
Fixes: c71b7eff426fa7 ("powerpc: Add ABIv2 support to ppc_function_entry")
Reported-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/code-patching.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
index eacc9102c2515c..d5b3c3bb95b400 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -73,7 +73,7 @@ void __patch_exception(int exc, unsigned long addr);
#endif
#define OP_RT_RA_MASK 0xffff0000UL
-#define LIS_R2 0x3c020000UL
+#define LIS_R2 0x3c400000UL
#define ADDIS_R2_R12 0x3c4c0000UL
#define ADDI_R2_R2 0x38420000UL
base-commit: 91966823812efbd175f904599e5cf2a854b39809
--
2.25.1
^ permalink raw reply related
* Re: Build regressions/improvements in v5.12-rc1
From: Christophe Leroy @ 2021-03-05 11:16 UTC (permalink / raw)
To: Geert Uytterhoeven, Alex Deucher
Cc: Alex Deucher, linuxppc-dev, LKML, amd-gfx list,
Christian König
In-Reply-To: <CAMuHMdVFstnce-WKmj=4h3ZdtSThJNOLz_f1ervcZxE6hg=KsA@mail.gmail.com>
Le 02/03/2021 à 21:01, Geert Uytterhoeven a écrit :
> Hi Alex,
>
> On Tue, Mar 2, 2021 at 8:30 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Mon, Mar 1, 2021 at 9:21 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Mon, 1 Mar 2021, Geert Uytterhoeven wrote:
>>>> Below is the list of build error/warning regressions/improvements in
>>>> v5.12-rc1[1] compared to v5.11[2].
>>>>
>>>> Summarized:
>>>> - build errors: +2/-0
>>>
>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8/ (all 192 configs)
>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f40ddce88593482919761f74910f42f4b84c004b/ (all 192 configs)
>>>>
>>>>
>>>> *** ERRORS ***
>>>>
>>>> 2 error regressions:
>>>> + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'disable_kernel_vsx' [-Werror=implicit-function-declaration]: => 674:2
>>>> + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'enable_kernel_vsx' [-Werror=implicit-function-declaration]: => 638:2
>>>
>>> powerpc-gcc4.9/ppc64_book3e_allmodconfig
>>>
>>> This was fixed in v5.11-rc1, but reappeared in v5.12-rc1?
>>
>> Do you know what fixed in for 5.11? I guess for PPC64 we depend on CONFIG_VSX?
>
> Looking at the kisskb build logs for v5.11*, it seems compilation never
> got to drivers/gpu/drm/ due to internal compiler errors that weren't caught
> by my scripts. So the errors listed above were not really fixed.
>
As far as I can see, the problem has been there for any config without CONFIG_VSX from the beginning
ie since https://github.com/linuxppc/linux/commit/16a9dea110a6
The following should fix it up:
diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index fdab93428372..9d1fbd8be1c7 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -71,6 +71,16 @@ static inline void disable_kernel_vsx(void)
{
msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
}
+#else
+static inline void enable_kernel_vsx(void)
+{
+ BUILD_BUG();
+}
+
+static inline void disable_kernel_vsx(void)
+{
+ BUILD_BUG();
+}
#endif
#ifdef CONFIG_SPE
---
Christophe
Christophe
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix instruction encoding for lis in ppc_function_entry()
From: Christophe Leroy @ 2021-03-05 11:37 UTC (permalink / raw)
To: Naveen N. Rao, linuxppc-dev; +Cc: Jiri Olsa
In-Reply-To: <20210304020411.16796-1-naveen.n.rao@linux.vnet.ibm.com>
Le 04/03/2021 à 03:04, Naveen N. Rao a écrit :
> 'lis r2,N' is 'addis r2,0,N' and the instruction encoding in the macro
> LIS_R2 is incorrect (it currently maps to 'addis 0,r2,N'). Fix the same.
>
> Fixes: c71b7eff426fa7 ("powerpc: Add ABIv2 support to ppc_function_entry")
> Reported-by: Jiri Olsa <jolsa@redhat.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/code-patching.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
> index eacc9102c2515c..d5b3c3bb95b400 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -73,7 +73,7 @@ void __patch_exception(int exc, unsigned long addr);
> #endif
>
> #define OP_RT_RA_MASK 0xffff0000UL
> -#define LIS_R2 0x3c020000UL
> +#define LIS_R2 0x3c400000UL
> #define ADDIS_R2_R12 0x3c4c0000UL
> #define ADDI_R2_R2 0x38420000UL
That probably goes beyond the scope of this patch, but it would be more readable and less error
prone to use macros defined in ppc-opcode.h just like kernel/module_64.c does for instance:
#define LIS_R2 (PPC_INST_ADDIS | __PPC_RT(R2))
#define ADDIS_R2_R12 (PPC_INST_ADDIS | __PPC_RT(R2) | __PPC_RA(R12))
#define ADDI_R2_R2 (PPC_INST_ADDI | __PPC_RT(R2) | __PPC_RA(R2))
>
>
> base-commit: 91966823812efbd175f904599e5cf2a854b39809
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: export LPAR security flavor in lparcfg
From: Michael Ellerman @ 2021-03-05 11:43 UTC (permalink / raw)
To: Laurent Dufour, benh, paulus, linuxppc-dev; +Cc: nathanl, cheloha, linux-kernel
In-Reply-To: <2c67c119-c1ec-b079-da54-0bf2f316c734@linux.ibm.com>
Laurent Dufour <ldufour@linux.ibm.com> writes:
> Le 05/03/2021 à 07:23, Michael Ellerman a écrit :
>> Laurent Dufour <ldufour@linux.ibm.com> writes:
>>> This is helpful to read the security flavor from inside the LPAR.
>>
>> We already have /sys/kernel/debug/powerpc/security_features.
>>
>> Is that not sufficient?
>
> Not really, it only reports that security mitigation are on or off but not the
> level set through the ASMI menu. Furthermore, reporting it through
> /proc/powerpc/lparcfg allows an easy processing by the lparstat command (see below).
>
>>
>>> Export it like this in /proc/powerpc/lparcfg:
>>>
>>> $ grep security_flavor /proc/powerpc/lparcfg
>>> security_flavor=1
>>>
>>> Value means:
>>> 0 Speculative execution fully enabled
>>> 1 Speculative execution controls to mitigate user-to-kernel attacks
>>> 2 Speculative execution controls to mitigate user-to-kernel and
>>> user-to-user side-channel attacks
>>
>> Those strings come from the FSP help, but we have no guarantee it won't
>> mean something different in future.
>
> I think this is nailed down, those strings came from:
> https://www.ibm.com/support/pages/node/715841
>
> Where it is written (regarding AIX):
>
> On an LPAR, one can use lparstat -x to display the current mitigation mode:
> 0 = Speculative execution fully enabled
> 1 = Speculative execution controls to mitigate user-to-kernel side-channel attacks
> 2 = Speculative execution controls to mitigate user-to-kernel and user-to-user
> side-channel attacks
>
> We have been requested to provide almost the same, which I proposed in
> powerpc-utils:
> https://groups.google.com/g/powerpc-utils-devel/c/NaKXvdyl_UI/m/wa2stpIDAQAJ
OK. Do you mind sending a v2 with all those details incorporated into
the change log?
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: export LPAR security flavor in lparcfg
From: Laurent Dufour @ 2021-03-05 11:45 UTC (permalink / raw)
To: Michael Ellerman, benh, paulus, linuxppc-dev
Cc: nathanl, cheloha, linux-kernel
In-Reply-To: <87wnulrfk4.fsf@mpe.ellerman.id.au>
Le 05/03/2021 à 12:43, Michael Ellerman a écrit :
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> Le 05/03/2021 à 07:23, Michael Ellerman a écrit :
>>> Laurent Dufour <ldufour@linux.ibm.com> writes:
>>>> This is helpful to read the security flavor from inside the LPAR.
>>>
>>> We already have /sys/kernel/debug/powerpc/security_features.
>>>
>>> Is that not sufficient?
>>
>> Not really, it only reports that security mitigation are on or off but not the
>> level set through the ASMI menu. Furthermore, reporting it through
>> /proc/powerpc/lparcfg allows an easy processing by the lparstat command (see below).
>>
>>>
>>>> Export it like this in /proc/powerpc/lparcfg:
>>>>
>>>> $ grep security_flavor /proc/powerpc/lparcfg
>>>> security_flavor=1
>>>>
>>>> Value means:
>>>> 0 Speculative execution fully enabled
>>>> 1 Speculative execution controls to mitigate user-to-kernel attacks
>>>> 2 Speculative execution controls to mitigate user-to-kernel and
>>>> user-to-user side-channel attacks
>>>
>>> Those strings come from the FSP help, but we have no guarantee it won't
>>> mean something different in future.
>>
>> I think this is nailed down, those strings came from:
>> https://www.ibm.com/support/pages/node/715841
>>
>> Where it is written (regarding AIX):
>>
>> On an LPAR, one can use lparstat -x to display the current mitigation mode:
>> 0 = Speculative execution fully enabled
>> 1 = Speculative execution controls to mitigate user-to-kernel side-channel attacks
>> 2 = Speculative execution controls to mitigate user-to-kernel and user-to-user
>> side-channel attacks
>>
>> We have been requested to provide almost the same, which I proposed in
>> powerpc-utils:
>> https://groups.google.com/g/powerpc-utils-devel/c/NaKXvdyl_UI/m/wa2stpIDAQAJ
>
> OK. Do you mind sending a v2 with all those details incorporated into
> the change log?
Ok will do so.
Thanks
^ permalink raw reply
* Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32
From: Michael Ellerman @ 2021-03-05 11:49 UTC (permalink / raw)
To: Marco Elver, Christophe Leroy
Cc: LKML, kasan-dev, Alexander Potapenko, Paul Mackerras,
linuxppc-dev, Dmitry Vyukov
In-Reply-To: <CANpmjNM9o1s4O4v2T9HUohPdCDJzWcaC5KDrt_7BSVdTUQWagw@mail.gmail.com>
Marco Elver <elver@google.com> writes:
...
>
> The choice is between:
>
> 1. ARCH_FUNC_PREFIX (as a matter of fact, the ARCH_FUNC_PREFIX patch
> is already in -mm). Perhaps we could optimize it further, by checking
> ARCH_FUNC_PREFIX in buf, and advancing buf like you propose, but I'm
> not sure it's worth worrying about.
>
> 2. The dynamic solution that I proposed that does not use a hard-coded
> '.' (or some variation thereof).
>
> Please tell me which solution you prefer, 1 or 2 -- I'd like to stop
> bikeshedding here. If there's a compelling argument for hard-coding
> the '.' in non-arch code, please clarify, but otherwise I'd like to
> keep arch-specific things out of generic code.
It's your choice, I was just trying to minimise the size of the wart you
have to carry in kfence code to deal with it.
The ARCH_FUNC_PREFIX solution is fine by me.
cheers
^ permalink raw reply
* [PATCH v4] powerpc/uprobes: Validation for prefixed instruction
From: Ravi Bangoria @ 2021-03-05 11:54 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, oleg, rostedt, linux-kernel, paulus,
sandipan, naveen.n.rao, linuxppc-dev
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.
There are two ways probed instruction is changed in mapped pages.
First, when Uprobe is activated, it searches for all the relevant
pages and replace instruction in them. In this case, if that probe
is on the 64-byte unaligned prefixed instruction, error out
directly. Second, when Uprobe is already active and user maps a
relevant page via mmap(), instruction is replaced via mmap() code
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
v3: https://lore.kernel.org/r/20210304050529.59391-1-ravi.bangoria@linux.ibm.com
v3->v4:
- CONFIG_PPC64 check was not required, remove it.
- Use SZ_ macros instead of hardcoded numbers.
arch/powerpc/kernel/uprobes.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index e8a63713e655..4cbfff6e94a3 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -41,6 +41,13 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
+ if (cpu_has_feature(CPU_FTR_ARCH_31) &&
+ ppc_inst_prefixed(auprobe->insn) &&
+ (addr & (SZ_64 - 4)) == SZ_64 - 4) {
+ pr_info_ratelimited("Cannot register a uprobe on 64 byte unaligned prefixed instruction\n");
+ return -EINVAL;
+ }
+
return 0;
}
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v2 1/7] cmdline: Add generic function to build command line.
From: Michael Ellerman @ 2021-03-05 11:58 UTC (permalink / raw)
To: Will Deacon, Christophe Leroy
Cc: linux-arch, robh, daniel, devicetree, linux-kernel,
Paul Mackerras, linuxppc-dev, danielwa
In-Reply-To: <20210303181651.GE19713@willie-the-truck>
Will Deacon <will@kernel.org> writes:
> On Wed, Mar 03, 2021 at 06:57:09PM +0100, Christophe Leroy wrote:
>> Le 03/03/2021 à 18:46, Will Deacon a écrit :
>> > On Wed, Mar 03, 2021 at 06:38:16PM +0100, Christophe Leroy wrote:
>> > > Le 03/03/2021 à 18:28, Will Deacon a écrit :
>> > > > On Tue, Mar 02, 2021 at 05:25:17PM +0000, Christophe Leroy wrote:
>> > > > > This code provides architectures with a way to build command line
>> > > > > based on what is built in the kernel and what is handed over by the
>> > > > > bootloader, based on selected compile-time options.
>> > > > >
>> > > > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> > > > > ---
>> > > > > include/linux/cmdline.h | 62 +++++++++++++++++++++++++++++++++++++++++
>> > > > > 1 file changed, 62 insertions(+)
>> > > > > create mode 100644 include/linux/cmdline.h
>> > > > >
>> > > > > diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>> > > > > new file mode 100644
>> > > > > index 000000000000..ae3610bb0ee2
>> > > > > --- /dev/null
>> > > > > +++ b/include/linux/cmdline.h
>> > > > > @@ -0,0 +1,62 @@
>> > > > > +/* SPDX-License-Identifier: GPL-2.0 */
>> > > > > +#ifndef _LINUX_CMDLINE_H
>> > > > > +#define _LINUX_CMDLINE_H
>> > > > > +
>> > > > > +static __always_inline size_t cmdline_strlen(const char *s)
>> > > > > +{
>> > > > > + const char *sc;
>> > > > > +
>> > > > > + for (sc = s; *sc != '\0'; ++sc)
>> > > > > + ; /* nothing */
>> > > > > + return sc - s;
>> > > > > +}
>> > > > > +
>> > > > > +static __always_inline size_t cmdline_strlcat(char *dest, const char *src, size_t count)
>> > > > > +{
>> > > > > + size_t dsize = cmdline_strlen(dest);
>> > > > > + size_t len = cmdline_strlen(src);
>> > > > > + size_t res = dsize + len;
>> > > > > +
>> > > > > + /* This would be a bug */
>> > > > > + if (dsize >= count)
>> > > > > + return count;
>> > > > > +
>> > > > > + dest += dsize;
>> > > > > + count -= dsize;
>> > > > > + if (len >= count)
>> > > > > + len = count - 1;
>> > > > > + memcpy(dest, src, len);
>> > > > > + dest[len] = 0;
>> > > > > + return res;
>> > > > > +}
>> > > >
>> > > > Why are these needed instead of using strlen and strlcat directly?
>> > >
>> > > Because on powerpc (at least), it will be used in prom_init, it is very
>> > > early in the boot and KASAN shadow memory is not set up yet so calling
>> > > generic string functions would crash the board.
>> >
>> > Hmm. We deliberately setup a _really_ early shadow on arm64 for this, can
>> > you not do something similar? Failing that, I think it would be better to
>> > offer the option for an arch to implement cmdline_*, but have then point to
>> > the normal library routines by default.
>>
>> I don't think it is possible to setup an earlier early shadow.
>>
>> At the point we are in prom_init, the code is not yet relocated at the
>> address it was linked for, and it is running with the MMU set by the
>> bootloader, I can't imagine being able to setup MMU entries for the early
>> shadow KASAN yet without breaking everything.
>
> That's very similar to us; we're not relocated, although we are at least
> in control of the MMU (which is using a temporary set of page-tables).
prom_init runs as an OF client, with the MMU off (except on some Apple
machines), and we don't own the MMU. So there's really nothing we can do :)
Though now that I look at it, I don't think we should be doing this
level of commandline handling in prom_init. It should just grab the
value from firmware and pass it to the kernel proper, and then all the
prepend/append/force etc. logic should happen there.
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/32: remove bogus ppc_select syscall
From: Arnd Bergmann @ 2021-03-05 12:03 UTC (permalink / raw)
To: Christophe Leroy
Cc: Paul Mackerras, linuxppc-dev, linux-kernel@vger.kernel.org
In-Reply-To: <5811950d-ef14-d416-35e6-d694ef920a7d@csgroup.eu>
On Fri, Mar 5, 2021 at 11:15 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 05/03/2021 à 11:06, Arnd Bergmann a écrit :
> > On Fri, Mar 5, 2021 at 9:40 AM Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> > - glibc support for ppc32 gets merged during the linux-2.5 days, supporting
> > only #142 with the new behavior.
It turns out to be older than I said. This was actually in glibc-1.94
from 1997, so during
the linux-2.1 days, not 2.5!
> Whaou, nice archeology, thanks. Do you mind if I copy the history you established ?
That's fine, please copy it.
> In your commit, you said 2.3.48. Here in the history you say 2.1.48. Which one is correct ?
2.1.48 is correct.
> Regardless of whethere binaries are broken or not for other reason, is that worth expecting an
> almost 25 yr old binary to run on future kernels ? If one is able to put the necessary effort to
> port you hardware to the latest kernel, can't he really port the binary as well ?
I think the questions of supporting old hardware with new software and
supporting old
binaries on modern kernels are largely orthogonal. The policy we have
is that we don't
break existing user setups, and it really seems unlikely that anyone
still uses pre-1997
executables for anything that requires a modern kernel!
I now checked the oldest mklinux I could find (DR2.1 from 1997), and
even has the
modern glibc and linux-2.0.28 kernel patched to provide the modern semantics at
syscall #142 for glibc, with the same (already unused) compatibility hack at #82
that we still have for ppc32 today. This made mklinux DR2.1 binaries
incompatible
with mainline linux-2.0 kernels, but they might still work with modern kernels,
regardless of whether we remove support for binaries that worked with mainline
linux-2.0.
Arnd
^ permalink raw reply
* Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends
From: Mark Rutland @ 2021-03-05 12:04 UTC (permalink / raw)
To: Marco Elver
Cc: Catalin Marinas, Will Deacon, LKML, broonie, Paul Mackerras,
kasan-dev, linux-toolchains, linuxppc-dev, Linux ARM
In-Reply-To: <CANpmjNMQNWBtWS7O_aaCfbMWvQUnzWTPXoxgD8DzqNzKfL_2Dg@mail.gmail.com>
On Thu, Mar 04, 2021 at 08:01:29PM +0100, Marco Elver wrote:
> On Thu, 4 Mar 2021 at 19:51, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote:
> > > I was having this problem with KCSAN, where the compiler would
> > > tail-call-optimize __tsan_X instrumentation.
> >
> > Those are compiler-generated calls, right? When those are generated the
> > compilation unit (and whatever it has included) might not have provided
> > a prototype anyway, and the compiler has special knowledge of the
> > functions, so it feels like the compiler would need to inhibit TCO here
> > for this to be robust. For their intended usage subjecting them to TCO
> > doesn't seem to make sense AFAICT.
> >
> > I suspect that compilers have some way of handling that; otherwise I'd
> > expect to have heard stories of mcount/fentry calls getting TCO'd and
> > causing problems. So maybe there's an easy fix there?
>
> I agree, the compiler builtins should be handled by the compiler
> directly, perhaps that was a bad example. But we also have "explicit
> instrumentation", e.g. everything that's in <linux/instrumented.h>.
True -- I agree for those we want similar, and can see a case for a
no-tco-calls-to-me attribute on functions as with noreturn.
Maybe for now it's worth adding prevent_tail_call_optimization() to the
instrument_*() call wrappers in <linux/instrumented.h>? As those are
__always_inline, that should keep the function they get inlined in
around. Though we probably want to see if we can replace the mb() in
prevent_tail_call_optimization() with something that doesn't require a
real CPU barrier.
[...]
> > I reckon for basically any instrumentation we don't want calls to be
> > TCO'd, though I'm not immediately sure of cases beyond sanitizers and
> > mcount/fentry.
>
> Thinking about this more, I think it's all debugging tools. E.g.
> lockdep, if you lock/unlock at the end of a function, you might tail
> call into lockdep. If the compiler applies TCO, and lockdep determines
> there's a bug and then shows a trace, you'll have no idea where the
> actual bug is. The kernel has lots of debugging facilities that add
> instrumentation in this way. So perhaps it's a general debugging-tool
> problem (rather than just sanitizers).
This makes sense to me.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH V3] mm: Generalize HUGETLB_PAGE_SIZE_VARIABLE
From: Michael Ellerman @ 2021-03-05 12:12 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: linux-ia64, Anshuman Khandual, linux-kernel, Paul Mackerras,
Andrew Morton, linuxppc-dev, Christoph Hellwig
In-Reply-To: <1614914928-22039-1-git-send-email-anshuman.khandual@arm.com>
Anshuman Khandual <anshuman.khandual@arm.com> writes:
> HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual
> platform subscribing it. Instead just make it generic.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: linux-ia64@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This change was originally suggested in an earilier discussion. This
> applies on v5.12-rc1 and has been build tested on all applicable
> platforms i.e ia64 and powerpc.
>
> https://patchwork.kernel.org/project/linux-mm/patch/1613024531-19040-3-git-send-email-anshuman.khandual@arm.com/
>
> Changes in V3:
>
> - Dropped the bool desciption that enabled user selection
> - Dropped the dependency on HUGETLB_PAGE for HUGETLB_PAGE_SIZE_VARIABLE
>
> Changes in V2:
>
> https://patchwork.kernel.org/project/linux-mm/patch/1614661987-23881-1-git-send-email-anshuman.khandual@arm.com/
>
> - Added a description for HUGETLB_PAGE_SIZE_VARIABLE
> - Added HUGETLB_PAGE dependency while selecting HUGETLB_PAGE_SIZE_VARIABLE
>
> Changes in V1:
>
> https://patchwork.kernel.org/project/linux-mm/patch/1614577853-7452-1-git-send-email-anshuman.khandual@arm.com/
>
> arch/ia64/Kconfig | 6 +-----
> arch/powerpc/Kconfig | 6 +-----
LGTM.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [PATCH v2 1/7] cmdline: Add generic function to build command line.
From: Christophe Leroy @ 2021-03-05 12:49 UTC (permalink / raw)
To: Michael Ellerman, Will Deacon
Cc: linux-arch, robh, daniel, devicetree, linux-kernel,
Paul Mackerras, linuxppc-dev, danielwa
In-Reply-To: <87sg59rewl.fsf@mpe.ellerman.id.au>
Le 05/03/2021 à 12:58, Michael Ellerman a écrit :
> Will Deacon <will@kernel.org> writes:
>> On Wed, Mar 03, 2021 at 06:57:09PM +0100, Christophe Leroy wrote:
>>> Le 03/03/2021 à 18:46, Will Deacon a écrit :
>>>> On Wed, Mar 03, 2021 at 06:38:16PM +0100, Christophe Leroy wrote:
>>>>> Le 03/03/2021 à 18:28, Will Deacon a écrit :
>>>>>> On Tue, Mar 02, 2021 at 05:25:17PM +0000, Christophe Leroy wrote:
>>>>>>> This code provides architectures with a way to build command line
>>>>>>> based on what is built in the kernel and what is handed over by the
>>>>>>> bootloader, based on selected compile-time options.
>>>>>>>
>>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>>>>> ---
>>>>>>> include/linux/cmdline.h | 62 +++++++++++++++++++++++++++++++++++++++++
>>>>>>> 1 file changed, 62 insertions(+)
>>>>>>> create mode 100644 include/linux/cmdline.h
>>>>>>>
>>>>>>> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..ae3610bb0ee2
>>>>>>> --- /dev/null
>>>>>>> +++ b/include/linux/cmdline.h
>>>>>>> @@ -0,0 +1,62 @@
>>>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>>>> +#ifndef _LINUX_CMDLINE_H
>>>>>>> +#define _LINUX_CMDLINE_H
>>>>>>> +
>>>>>>> +static __always_inline size_t cmdline_strlen(const char *s)
>>>>>>> +{
>>>>>>> + const char *sc;
>>>>>>> +
>>>>>>> + for (sc = s; *sc != '\0'; ++sc)
>>>>>>> + ; /* nothing */
>>>>>>> + return sc - s;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static __always_inline size_t cmdline_strlcat(char *dest, const char *src, size_t count)
>>>>>>> +{
>>>>>>> + size_t dsize = cmdline_strlen(dest);
>>>>>>> + size_t len = cmdline_strlen(src);
>>>>>>> + size_t res = dsize + len;
>>>>>>> +
>>>>>>> + /* This would be a bug */
>>>>>>> + if (dsize >= count)
>>>>>>> + return count;
>>>>>>> +
>>>>>>> + dest += dsize;
>>>>>>> + count -= dsize;
>>>>>>> + if (len >= count)
>>>>>>> + len = count - 1;
>>>>>>> + memcpy(dest, src, len);
>>>>>>> + dest[len] = 0;
>>>>>>> + return res;
>>>>>>> +}
>>>>>>
>>>>>> Why are these needed instead of using strlen and strlcat directly?
>>>>>
>>>>> Because on powerpc (at least), it will be used in prom_init, it is very
>>>>> early in the boot and KASAN shadow memory is not set up yet so calling
>>>>> generic string functions would crash the board.
>>>>
>>>> Hmm. We deliberately setup a _really_ early shadow on arm64 for this, can
>>>> you not do something similar? Failing that, I think it would be better to
>>>> offer the option for an arch to implement cmdline_*, but have then point to
>>>> the normal library routines by default.
>>>
>>> I don't think it is possible to setup an earlier early shadow.
>>>
>>> At the point we are in prom_init, the code is not yet relocated at the
>>> address it was linked for, and it is running with the MMU set by the
>>> bootloader, I can't imagine being able to setup MMU entries for the early
>>> shadow KASAN yet without breaking everything.
>>
>> That's very similar to us; we're not relocated, although we are at least
>> in control of the MMU (which is using a temporary set of page-tables).
>
> prom_init runs as an OF client, with the MMU off (except on some Apple
> machines), and we don't own the MMU. So there's really nothing we can do :)
>
> Though now that I look at it, I don't think we should be doing this
> level of commandline handling in prom_init. It should just grab the
> value from firmware and pass it to the kernel proper, and then all the
> prepend/append/force etc. logic should happen there.
But then, how do you handle the command line parameters that are needed by prom_init ?
For instance, prom_init_mem() use 'prom_memory_limit', which comes from the "mem=" option in the
command line.
Christophe
^ permalink raw reply
* [PATCH v2] powerpc/pseries: export LPAR security flavor in lparcfg
From: Laurent Dufour @ 2021-03-05 12:55 UTC (permalink / raw)
To: mpe, benh, paulus, linuxppc-dev; +Cc: nathanl, cheloha, linux-kernel
This is helpful to read the security flavor from inside the LPAR.
In /sys/kernel/debug/powerpc/security_features it can be seen if
mitigations are on or off but the level set through the ASMI menu.
Furthermore, reporting it through /proc/powerpc/lparcfg allows an easy
processing by the lparstat command [1].
Export it like this in /proc/powerpc/lparcfg:
$ grep security_flavor /proc/powerpc/lparcfg
security_flavor=1
Value follows what is documented on the IBM support page [2]:
0 Speculative execution fully enabled
1 Speculative execution controls to mitigate user-to-kernel attacks
2 Speculative execution controls to mitigate user-to-kernel and
user-to-user side-channel attacks
[1] https://groups.google.com/g/powerpc-utils-devel/c/NaKXvdyl_UI/m/wa2stpIDAQAJ
[2] https://www.ibm.com/support/pages/node/715841
Changes since V1:
- Add details in the commit's description.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/platforms/pseries/lparcfg.c | 2 ++
arch/powerpc/platforms/pseries/pseries.h | 1 +
arch/powerpc/platforms/pseries/setup.c | 8 ++++++++
4 files changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index ed6086d57b22..455e188da26d 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -389,6 +389,7 @@
#define H_CPU_BEHAV_FAVOUR_SECURITY (1ull << 63) // IBM bit 0
#define H_CPU_BEHAV_L1D_FLUSH_PR (1ull << 62) // IBM bit 1
#define H_CPU_BEHAV_BNDS_CHK_SPEC_BAR (1ull << 61) // IBM bit 2
+#define H_CPU_BEHAV_FAVOUR_SECURITY_H (1ull << 60) // IBM bit 3
#define H_CPU_BEHAV_FLUSH_COUNT_CACHE (1ull << 58) // IBM bit 5
#define H_CPU_BEHAV_FLUSH_LINK_STACK (1ull << 57) // IBM bit 6
diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
index e278390ab28d..35f6c4929fbd 100644
--- a/arch/powerpc/platforms/pseries/lparcfg.c
+++ b/arch/powerpc/platforms/pseries/lparcfg.c
@@ -169,6 +169,7 @@ static void show_gpci_data(struct seq_file *m)
kfree(buf);
}
+
static unsigned h_pic(unsigned long *pool_idle_time,
unsigned long *num_procs)
{
@@ -537,6 +538,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
parse_em_data(m);
maxmem_data(m);
+ seq_printf(m, "security_flavor=%u\n", pseries_security_flavor);
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 4fe48c04c6c2..a25517dc2515 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -111,6 +111,7 @@ static inline unsigned long cmo_get_page_size(void)
int dlpar_workqueue_init(void);
+extern u32 pseries_security_flavor;
void pseries_setup_security_mitigations(void);
void pseries_lpar_read_hblkrm_characteristics(void);
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 46e1540abc22..59080413a269 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -85,6 +85,7 @@ EXPORT_SYMBOL(CMO_PageSize);
int fwnmi_active; /* TRUE if an FWNMI handler is present */
int ibm_nmi_interlock_token;
+u32 pseries_security_flavor;
static void pSeries_show_cpuinfo(struct seq_file *m)
{
@@ -534,9 +535,16 @@ static void init_cpu_char_feature_flags(struct h_cpu_char_result *result)
/*
* The features below are enabled by default, so we instead look to see
* if firmware has *disabled* them, and clear them if so.
+ * H_CPU_BEHAV_FAVOUR_SECURITY_H could be set only if
+ * H_CPU_BEHAV_FAVOUR_SECURITY is.
*/
if (!(result->behaviour & H_CPU_BEHAV_FAVOUR_SECURITY))
security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
+ else if (result->behaviour & H_CPU_BEHAV_FAVOUR_SECURITY_H)
+ pseries_security_flavor = 1;
+ else
+ pseries_security_flavor = 2;
+
if (!(result->behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
--
2.30.1
^ permalink raw reply related
* Re: [PATCH V3] mm: Generalize HUGETLB_PAGE_SIZE_VARIABLE
From: Christoph Hellwig @ 2021-03-05 12:56 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-ia64, linux-kernel, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <1614914928-22039-1-git-send-email-anshuman.khandual@arm.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix instruction encoding for lis in ppc_function_entry()
From: Jiri Olsa @ 2021-03-05 13:15 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev
In-Reply-To: <20210304020411.16796-1-naveen.n.rao@linux.vnet.ibm.com>
On Thu, Mar 04, 2021 at 07:34:11AM +0530, Naveen N. Rao wrote:
> 'lis r2,N' is 'addis r2,0,N' and the instruction encoding in the macro
> LIS_R2 is incorrect (it currently maps to 'addis 0,r2,N'). Fix the same.
>
> Fixes: c71b7eff426fa7 ("powerpc: Add ABIv2 support to ppc_function_entry")
> Reported-by: Jiri Olsa <jolsa@redhat.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/code-patching.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
> index eacc9102c2515c..d5b3c3bb95b400 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -73,7 +73,7 @@ void __patch_exception(int exc, unsigned long addr);
> #endif
>
> #define OP_RT_RA_MASK 0xffff0000UL
> -#define LIS_R2 0x3c020000UL
> +#define LIS_R2 0x3c400000UL
> #define ADDIS_R2_R12 0x3c4c0000UL
> #define ADDI_R2_R2 0x38420000UL
>
>
> base-commit: 91966823812efbd175f904599e5cf2a854b39809
> --
> 2.25.1
>
I tested the new define value with uprobe issue we were dealing with
and now it matches the instruction, so it works for me
thanks a lot for the fix,
jirka
^ permalink raw reply
* Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32
From: Marco Elver @ 2021-03-05 13:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: LKML, Paul Mackerras, kasan-dev, Alexander Potapenko,
linuxppc-dev, Dmitry Vyukov
In-Reply-To: <87tupprfan.fsf@mpe.ellerman.id.au>
On Fri, 5 Mar 2021 at 12:49, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Marco Elver <elver@google.com> writes:
> ...
> >
> > The choice is between:
> >
> > 1. ARCH_FUNC_PREFIX (as a matter of fact, the ARCH_FUNC_PREFIX patch
> > is already in -mm). Perhaps we could optimize it further, by checking
> > ARCH_FUNC_PREFIX in buf, and advancing buf like you propose, but I'm
> > not sure it's worth worrying about.
> >
> > 2. The dynamic solution that I proposed that does not use a hard-coded
> > '.' (or some variation thereof).
> >
> > Please tell me which solution you prefer, 1 or 2 -- I'd like to stop
> > bikeshedding here. If there's a compelling argument for hard-coding
> > the '.' in non-arch code, please clarify, but otherwise I'd like to
> > keep arch-specific things out of generic code.
>
> It's your choice, I was just trying to minimise the size of the wart you
> have to carry in kfence code to deal with it.
>
> The ARCH_FUNC_PREFIX solution is fine by me.
Thank you -- the ARCH_FUNC_PREFIX version is already in -mm, so let's
keep it. It's purely static vs the other options. Should another
debugging tool need something similar we can revisit whether to change
or move it.
Thanks,
-- Marco
^ permalink raw reply
* [PATCH] ethernet: ucc_geth: Use kmemdup instead of kmalloc and memcpy
From: angkery @ 2021-03-05 14:27 UTC (permalink / raw)
To: leoyang.li, davem, kuba; +Cc: netdev, linuxppc-dev, linux-kernel, Junlin Yang
From: Junlin Yang <yangjunlin@yulong.com>
Fixes coccicheck warnings:
./drivers/net/ethernet/freescale/ucc_geth.c:3594:11-18:
WARNING opportunity for kmemdup
Signed-off-by: Junlin Yang <yangjunlin@yulong.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index ef4e2fe..2c079ad 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3591,10 +3591,9 @@ static int ucc_geth_probe(struct platform_device* ofdev)
if ((ucc_num < 0) || (ucc_num > 7))
return -ENODEV;
- ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
+ ug_info = kmemdup(&ugeth_primary_info, sizeof(*ug_info), GFP_KERNEL);
if (ug_info == NULL)
return -ENOMEM;
- memcpy(ug_info, &ugeth_primary_info, sizeof(*ug_info));
ug_info->uf_info.ucc_num = ucc_num;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 00/41] KVM: PPC: Book3S: C-ify the P9 entry/exit code
From: Nicholas Piggin @ 2021-03-05 15:05 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
This tidies up things, and fixes a few corner cases and unfinished
"XXX:" bits. The major one being "bad host interrupt" detection and
handling (taking a MCE/SRESET while switching into guest regs) which
was missing previously from the new P9 path.
Adds a few new patches and makes some changes for issues noticed
by reviewers (thank you).
Thanks,
Nick
Nicholas Piggin (41):
KVM: PPC: Book3S HV: Disallow LPCR[AIL] to be set to 1 or 2
KVM: PPC: Book3S HV: Prevent radix guests from setting LPCR[TC]
KVM: PPC: Book3S HV: Remove redundant mtspr PSPB
KVM: PPC: Book3S HV: remove unused kvmppc_h_protect argument
KVM: PPC: Book3S HV: Fix CONFIG_SPAPR_TCE_IOMMU=n default hcalls
powerpc/64s: Remove KVM handler support from CBE_RAS interrupts
powerpc/64s: remove KVM SKIP test from instruction breakpoint handler
KVM: PPC: Book3S HV: Ensure MSR[ME] is always set in guest MSR
KVM: PPC: Book3S 64: move KVM interrupt entry to a common entry point
KVM: PPC: Book3S 64: Move GUEST_MODE_SKIP test into KVM
KVM: PPC: Book3S 64: add hcall interrupt handler
KVM: PPC: Book3S 64: Move hcall early register setup to KVM
KVM: PPC: Book3S 64: Move interrupt early register setup to KVM
KVM: PPC: Book3S 64: move bad_host_intr check to HV handler
KVM: PPC: Book3S 64: Minimise hcall handler calling convention
differences
KVM: PPC: Book3S HV P9: Move radix MMU switching instructions together
KVM: PPC: Book3S HV P9: implement kvmppc_xive_pull_vcpu in C
KVM: PPC: Book3S HV P9: Move xive vcpu context management into
kvmhv_p9_guest_entry
KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9
path
KVM: PPC: Book3S HV P9: Move setting HDEC after switching to guest
LPCR
KVM: PPC: Book3S HV P9: Use large decrementer for HDEC
KVM: PPC: Book3S HV P9: Use host timer accounting to avoid decrementer
read
KVM: PPC: Book3S HV P9: Reduce mftb per guest entry/exit
powerpc: add set_dec_or_work API for safely updating decrementer
KVM: PPC: Book3S HV P9: Reduce irq_work vs guest decrementer races
KVM: PPC: Book3S HV P9: Implement the rest of the P9 path in C
KVM: PPC: Book3S HV P9: inline kvmhv_load_hv_regs_and_go into
__kvmhv_vcpu_entry_p9
KVM: PPC: Book3S HV P9: Read machine check registers while MSR[RI] is
0
KVM: PPC: Book3S HV P9: Improve exit timing accounting coverage
KVM: PPC: Book3S HV P9: Move SPR loading after expiry time check
KVM: PPC: Book3S HV P9: Add helpers for OS SPR handling
KVM: PPC: Book3S HV P9: Switch to guest MMU context as late as
possible
KVM: PPC: Book3S HV: Implement radix prefetch workaround by disabling
MMU
KVM: PPC: Book3S HV: Remove support for dependent threads mode on P9
KVM: PPC: Book3S HV: Remove radix guest support from P7/8 path
KVM: PPC: Book3S HV P9: Allow all P9 processors to enable nested HV
KVM: PPC: Book3S HV: small pseries_do_hcall cleanup
KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page
faults
KVM: PPC: Book3S HV P9: implement hash guest support
KVM: PPC: Book3S HV P9: implement hash host / hash guest support
KVM: PPC: Book3S HV: remove ISA v3.0 and v3.1 support from P7/8 path
arch/powerpc/include/asm/asm-prototypes.h | 3 +-
arch/powerpc/include/asm/exception-64s.h | 13 +
arch/powerpc/include/asm/kvm_asm.h | 3 +-
arch/powerpc/include/asm/kvm_book3s_64.h | 8 +
arch/powerpc/include/asm/kvm_host.h | 1 -
arch/powerpc/include/asm/kvm_ppc.h | 10 +-
arch/powerpc/include/asm/mmu_context.h | 6 -
arch/powerpc/include/asm/time.h | 16 +
arch/powerpc/kernel/exceptions-64s.S | 262 ++-------
arch/powerpc/kernel/security.c | 5 +-
arch/powerpc/kernel/time.c | 21 +-
arch/powerpc/kvm/Makefile | 6 +
arch/powerpc/kvm/book3s_64_entry.S | 368 ++++++++++++
arch/powerpc/kvm/book3s_hv.c | 669 +++++++++++-----------
arch/powerpc/kvm/book3s_hv_builtin.c | 6 +
arch/powerpc/kvm/book3s_hv_interrupt.c | 519 +++++++++++++++++
arch/powerpc/kvm/book3s_hv_interrupts.S | 9 +-
arch/powerpc/kvm/book3s_hv_nested.c | 10 +-
arch/powerpc/kvm/book3s_hv_ras.c | 2 +
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 15 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 625 +-------------------
arch/powerpc/kvm/book3s_segment.S | 7 +
arch/powerpc/kvm/book3s_xive.c | 91 +++
arch/powerpc/mm/book3s64/radix_pgtable.c | 27 +-
arch/powerpc/mm/book3s64/radix_tlb.c | 46 --
arch/powerpc/mm/mmu_context.c | 4 +-
arch/powerpc/platforms/powernv/idle.c | 52 +-
27 files changed, 1506 insertions(+), 1298 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_64_entry.S
create mode 100644 arch/powerpc/kvm/book3s_hv_interrupt.c
--
2.23.0
^ permalink raw reply
* [PATCH v3 01/41] KVM: PPC: Book3S HV: Disallow LPCR[AIL] to be set to 1 or 2
From: Nicholas Piggin @ 2021-03-05 15:05 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin, Fabiano Rosas
In-Reply-To: <20210305150638.2675513-1-npiggin@gmail.com>
These are already disallowed by H_SET_MODE from the guest, also disallow
these by updating LPCR directly.
AIL modes can affect the host interrupt behaviour while the guest LPCR
value is set, so filter it here too.
Suggested-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_hv.c | 11 +++++++++--
arch/powerpc/kvm/book3s_hv_nested.c | 7 +++++--
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 13bad6bf4c95..c40eeb20be39 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -803,7 +803,10 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, unsigned long mflags,
vcpu->arch.dawrx1 = value2;
return H_SUCCESS;
case H_SET_MODE_RESOURCE_ADDR_TRANS_MODE:
- /* KVM does not support mflags=2 (AIL=2) */
+ /*
+ * KVM does not support mflags=2 (AIL=2) and AIL=1 is reserved.
+ * Keep this in synch with kvmppc_set_lpcr.
+ */
if (mflags != 0 && mflags != 3)
return H_UNSUPPORTED_FLAG_START;
return H_TOO_HARD;
@@ -1667,8 +1670,12 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
* On POWER8 and POWER9 userspace can also modify AIL (alt. interrupt loc.).
*/
mask = LPCR_DPFD | LPCR_ILE | LPCR_TC;
- if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
mask |= LPCR_AIL;
+ /* LPCR[AIL]=1/2 is disallowed */
+ if ((new_lpcr & LPCR_AIL) && (new_lpcr & LPCR_AIL) != LPCR_AIL_3)
+ new_lpcr &= ~LPCR_AIL;
+ }
/*
* On POWER9, allow userspace to enable large decrementer for the
* guest, whether or not the host has it enabled.
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
index 2fe1fea4c934..b496079e02f7 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -139,9 +139,12 @@ static void sanitise_hv_regs(struct kvm_vcpu *vcpu, struct hv_guest_state *hr)
/*
* Don't let L1 change LPCR bits for the L2 except these:
+ * Keep this in sync with kvmppc_set_lpcr.
*/
- mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
- LPCR_LPES | LPCR_MER;
+ mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_LD | LPCR_LPES | LPCR_MER;
+ /* LPCR[AIL]=1/2 is disallowed */
+ if ((hr->lpcr & LPCR_AIL) && (hr->lpcr & LPCR_AIL) != LPCR_AIL_3)
+ hr->lpcr &= ~LPCR_AIL;
hr->lpcr = (vc->lpcr & ~mask) | (hr->lpcr & mask);
/*
--
2.23.0
^ permalink raw reply related
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