On Thu, Jun 3, 2021 at 2:53 PM Daniel Borkmann wrote:
> On 6/2/21 5:13 PM, Paul Moore wrote:
> [...]
> > Help me out here, is your answer that the access check can only be
> > done at BPF program load time? That isn't really a solution from a
> > SELinux perspective as far as I'm concerned.
>
>
PPC64 uses MMU features to enable/disable KUAP at boot time.
But feature fixups are applied way too early on PPC32.
But since commit c16728835eec ("powerpc/32: Manage KUAP in C"),
all KUAP is in C so it is now possible to use static branches.
Signed-off-by: Christophe Leroy
---
v2: Added
On Thu, 2021-06-03 at 14:38 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:33 pm:
> > Same vas_window struct is used on powerNV and pseries. So this
> > patch
> > changes in struct vas_window to support both platforms and also the
> > corresponding
On Thu, 2021-06-03 at 14:21 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:31 pm:
> > Take pid and mm references when each window opens and drops during
> > close. This functionality is needed for powerNV and pseries. So
> > this patch defines the existing
602
x86_64 randconfig-a005-20210602
x86_64 randconfig-a001-20210602
i386 randconfig-a003-20210603
i386 randconfig-a006-20210603
i386 randconfig-a004-20210603
i386 randconfig-a001-20210603
i386
On Thu, 2021-06-03 at 14:47 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:34 pm:
> > This patch adds HCALLs and other definitions. Also define structs
> > that are used in VAS implementation on powerVM.
> >
> > Signed-off-by: Haren Myneni
> > ---
> >
On Thu, 2021-06-03 at 15:48 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:39 pm:
> > NX generates an interrupt when sees a fault on the user space
> > buffer and the hypervisor forwards that interrupt to OS. Then
> > the kernel handles the interrupt by
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.13-rc4 next-20210603]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
On Thu, 2021-06-03 at 14:57 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:42 pm:
> > Changes to export the following NXGZIP capabilities through sysfs:
> >
> > /sys/devices/vio/ibm,compression-v1/NxGzCaps:
>
> Where's the horrible camel case name coming
On 4/06/21 12:42 pm, Michael Ellerman wrote:
> Sasha Levin writes:
>> From: Chris Packham
>>
>> [ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
>>
>> The i2c controllers on the P2040/P2041 have an erratum where the
>> documented scheme for i2c bus recovery will not work (A-004447).
Sasha Levin writes:
> From: Chris Packham
>
> [ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
>
> The i2c controllers on the P2040/P2041 have an erratum where the
> documented scheme for i2c bus recovery will not work (A-004447). A
> different mechanism is needed which is documented
https://bugzilla.kernel.org/show_bug.cgi?id=213069
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Geoff Levand writes:
> Hi Michael,
>
> On 6/2/21 10:38 PM, Michael Ellerman wrote:
>> Geoff Levand writes:
>>> Hi,
>>>
>>> This is a set of patches that fix various DMA related problems in the PS3
>>> device drivers, and add better error checking and improved message logging.
>>>
>>> The gelic
On Thu, 2021-06-03 at 14:05 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:30 pm:
> > PowerNV uses registers to open/close VAS windows, and getting the
> > paste address. Whereas the hypervisor calls are used on PowerVM.
> >
> > This patch adds the platform
On Thu, 2021-06-03 at 13:32 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of May 21, 2021 7:28 pm:
> > Using the same /dev/crypto/nx-gzip interface for both powerNV and
> > pseries. So this patch creates platforms/book3s/ and moves VAS API
> > to that directory. The actual
Hi Michael,
On 6/2/21 10:38 PM, Michael Ellerman wrote:
> Geoff Levand writes:
>> Hi,
>>
>> This is a set of patches that fix various DMA related problems in the PS3
>> device drivers, and add better error checking and improved message logging.
>>
>> The gelic network driver had a number of
Commit f959dcd6ddfd29235030e8026471ac1b022ad2b0 (dma-direct: Fix
potential NULL pointer dereference) added a null check on the
dma_mask pointer of the kernel's device structure.
Add a dma_mask variable to the ps3_dma_region structure and set
the device structure's dma_mask pointer to point to
To aid debugging PS3 boot problems change the log level
of several PS3 device errors from pr_debug to pr_warn.
Signed-off-by: Geoff Levand
---
arch/powerpc/platforms/ps3/system-bus.c | 9 +
drivers/ps3/ps3-vuart.c | 2 +-
drivers/ps3/ps3av.c | 22
To aid debugging, add a new PS3 kernel config option
PS3_VERBOSE_RESULT that, when enabled, will print more
verbose messages for the result of LV1 hypercalls.
Signed-off-by: Geoff Levand
---
arch/powerpc/include/asm/ps3.h | 2 +-
arch/powerpc/platforms/ps3/Kconfig | 9 +
2 files
Hi Michael,
This is a set of patches that fix various DMA related problems in the PS3
device drivers, and add better error checking and improved message logging.
Changes from V1:
Split the V1 series into two, one series with powerpc changes, and one series
with gelic network driver changes.
Hi Dave, Jakub,
This is a set of patches that fix various DMA related problems in the PS3
gelic network driver, and also adds better error checking and improved
message logging.
Please consider.
Changes from V1:
Split the V1 series into two, one series with powerpc changes, and one series
Create two new structures, struct gelic_hw_regs and struct gelic_chain_link,
and replace the corresponding members of struct gelic_descr with the new
structures. struct gelic_hw_regs holds the register variables used by the
gelic hardware device. struct gelic_chain_link holds variables used to
General source cleanups and improved logging messages.
Signed-off-by: Geoff Levand
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 395 ++-
1 file changed, 216 insertions(+), 179 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
On 6/2/21 5:13 PM, Paul Moore wrote:
[...]
Help me out here, is your answer that the access check can only be
done at BPF program load time? That isn't really a solution from a
SELinux perspective as far as I'm concerned.
That is the current answer. The unfortunate irony is that 59438b46471a
On Wed, Jun 2, 2021 at 9:40 AM Ondrej Mosnacek wrote:
> On Fri, May 28, 2021 at 3:37 AM Paul Moore wrote:
> > On Mon, May 17, 2021 at 5:22 AM Ondrej Mosnacek wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > > lockdown") added an implementation of the
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
From: Chris Packham
[ Upstream commit 19ae697a1e4edf1d755b413e3aa38da65e2db23b ]
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
From: Chris Packham
[ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q
On Wed, 2 Jun 2021 at 08:54, Christoph Hellwig wrote:
>
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/memstick/core/mspro_block.c | 26
On Wed, 2 Jun 2021 at 08:54, Christoph Hellwig wrote:
>
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/memstick/core/ms_block.c | 25
On 6/3/21 12:53 AM, Christophe Leroy wrote:
Since commit Fixes: 555904d07eef ("powerpc/8xx: MM_SLICE is not needed
anymore"),
CONFIG_PPC_MMU_NOHASH_32 has not been used.
Remove it.
Reported-by: Tom Rix
Signed-off-by: Christophe Leroy
Thanks, one less for me to do.
There are about ~100
DEBUG_HARDER is not user selectable.
Remove it together with related messages.
Also remove two pr_devel() messages that should
likely have been pr_hard().
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/mmu_context.c | 32
1 file changed, 32
DEBUG_CLAMP_LAST_CONTEXT was there in the old days to reduce
number of contexts in order to ease debugging implementation
of context switching, but that's been quite stable during
years now.
As it is not user selectable, remove it.
Signed-off-by: Christophe Leroy
---
mmu_context handling has been there for years, so we
would know if there was problems with maps.
DEBUG_MAP_CONSISTENCY is not user selectable, remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/mmu_context.c | 47 +---
1 file changed, 1 insertion(+),
Everything can be done even when CONFIG_SMP is not selected.
Just use IS_ENABLED() where relevant and rely on GCC to
opt out unneeded code and variables when CONFIG_SMP is not set.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/mmu_context.c | 66 ++--
1
ppc8xx already has set_context() in C.
Other ones have it in assembly. The only thing it does is to
write the context id into SPRN_PID.
Do it in C.
Signed-off-by: Christophe Leroy
---
v3: Fixed whitespace before tab
---
arch/powerpc/include/asm/mmu_context.h | 1 -
Instead of duplicating the update of BDI2000 pointers in
set_context(), do it directly from switch_mmu_context().
Signed-off-by: Christophe Leroy
---
v3: Do it only for nohash platforms, book3s/32 will have its own as part of
converting switch_mmu_context() to C.
---
All KUAP helpers defined in asm/kup.h are single line functions
that should be inlined. But on book3s/32 build, we get many
instances of .
Force inlining of those helpers.
Signed-off-by: Christophe Leroy
---
Was previously part of a series, resending standalone as it really is
independant.
---
PPC64 uses MMU features to enable/disable KUAP at boot time.
But feature fixups are applied way too early on PPC32.
But since commit c16728835eec ("powerpc/32: Manage KUAP in C"),
all KUAP is in C so it is now possible to use static branches.
Signed-off-by: Christophe Leroy
---
prevent_user_access() doesn't use anymore to/from/size parameters.
Remove them.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/kup.h | 3 +--
arch/powerpc/include/asm/book3s/64/kup.h | 3 +--
arch/powerpc/include/asm/kup.h | 15 +++
book3s/32 was the only user of KUAP_CURRENT_XXX.
After rework of book3s/32 KUAP, it is not used anymore.
Remove them.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/kup.h | 1 -
arch/powerpc/include/asm/kup.h | 14 +++---
2 files changed, 3
Now that KUAP and KUEP have been significantly optimised and can be
disabled at boot time using 'nosmap' and 'nosmep' kernel parameters,
them can be active by default like in other powerpc platforms.
It is still possible to disable them completely in the configuration.
Signed-off-by: Christophe
On book3s/32, KUAP is provided by toggling Ks bit in segment registers.
One segment register addresses 256M of virtual memory.
At the time being, KUAP implements a complex logic to apply the
unlock/lock on the exact number of segments covering the user range
to access, with saving the boundaries
PPC64 uses MMU features to enable/disable KUAP at boot time.
But feature fixups are applied way too early on PPC32.
Now that all KUAP related actions are in C following the
conversion of KUAP initial setup and context switch in C,
static branches can be used to enable/disable KUAP.
PPC64 uses MMU features to enable/disable KUEP at boot time.
But feature fixups are applied way too early on PPC32.
Now that all KUEP related actions are in C following the
conversion of KUEP initial setup and context switch in C,
static branches can be used to enable/disable KUEP.
In order to selectively activate KUAP and KUEP in a following patch,
perform KUAP and KUEP initialisation in C.
Unlike PPC64, PPC32 doesn't have an early_setup_secondary(),
so do it in start_secondary().
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_book3s_32.S | 6 --
segment register has VSID on bits 8-31.
Bits 4-7 are reserved, there is no requirement to set them to 0.
VSIDs are calculated from VSID of SR0 by adding 0x111.
Even with highest possible VSID which would be 0xF0,
adding 16 times 0x111 results in 0x1001100.
So, the reserved bits are never
switch_mmu_context() does things that can easily be done in C.
For updating user segments, we have update_user_segments().
As mentionned in commit b5efec00b671 ("powerpc/32s: Move KUEP
locking/unlocking in C"), update_user_segments() has the loop
unrolled which is a significant performance gain.
From: Christophe Leroy
In order to reuse it in switch_mmu_context(), this
patch moves CTX_TO_VSID() macro into asm/book3s/32/mmu-hash.h
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 10 ++
arch/powerpc/kvm/book3s_32_mmu_host.c | 3 ---
KUEP implements the update of user segment registers.
Move it into mmu-hash.h in order to use it from other places.
And inline kuep_lock() and kuep_unlock(). Inlining kuep_lock() is
important for system_call_exception(), otherwise system_call_exception()
has to save into stack the system call
Avoids the #ifdef in mmu.c
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/Makefile | 1 +
arch/powerpc/mm/book3s32/kuap.c | 11 +++
arch/powerpc/mm/book3s32/kuep.c | 8
arch/powerpc/mm/book3s32/mmu.c| 20
4 files changed, 20
This series is a rework of KUAP on book3s/32.
On book3s32, KUAP is heavier than on other platform because it can't
be opened globaly at once, it must be done for each 256Mb segment.
Instead of opening access to all necessary segments via a heavy logic,
only open access to the segment matching
Since commit Fixes: 555904d07eef ("powerpc/8xx: MM_SLICE is not needed
anymore"),
CONFIG_PPC_MMU_NOHASH_32 has not been used.
Remove it.
Reported-by: Tom Rix
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/Kconfig.cputype | 4
1 file changed, 4 deletions(-)
diff --git
64 matches
Mail list logo
