Currently access to perf_events, i915_perf and other performance
monitoring and observability subsystems of the kernel is open only for
a privileged process [1] with CAP_SYS_ADMIN capability enabled in the
process effective set [2].
This patch set introduces CAP_PERFMON capability designed to se
Introduce CAP_PERFMON capability designed to secure system performance
monitoring and observability operations so that CAP_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for performance
monitoring and observability subsystems.
CAP_PERFMON hardens system security and integrit
Open access to monitoring of kernel code, cpus, tracepoints and
namespaces data for a CAP_PERFMON privileged process. Providing the
access under CAP_PERFMON capability singly, without the rest of
CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials
and makes operation more secure
Open access to monitoring via kprobes and uprobes and eBPF tracing for
CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
capability singly, without the rest of CAP_SYS_ADMIN credentials,
excludes chances to misuse the credentials and makes operation more
secure.
perf kprobes
Extend error messages to mention CAP_PERFMON capability as an option
to substitute CAP_SYS_ADMIN capability for secure system performance
monitoring and observability. Make perf_event_paranoid_check() and
__cmd_ftrace() to be aware of CAP_PERFMON capability.
CAP_PERFMON implements the principal
Open access to i915_perf monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of lea
Open access to bpf_trace monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of lea
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without
the rest of CAP_SYS_ADMIN credentials, excludes chances to misuse
the credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without
the rest of CAP_SYS_ADMIN credentials, excludes chances to misuse
the credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without
the rest of CAP_SYS_ADMIN credentials, excludes chances to misuse
the credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without
the rest of CAP_SYS_ADMIN credentials, excludes chances to misuse
the credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Update perf-security.rst documentation file with the information
related to usage of CAP_PERFMON capability to secure performance
monitoring and observability operations in system.
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/perf-security.rst | 65 +
1 file
Update kernel.rst documentation file with the information
related to usage of CAP_PERFMON capability to secure performance
monitoring and observability operations in system.
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/sysctl/kernel.rst | 16 +++-
1 file changed, 11
Le 14/02/2020 à 16:41, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
Hi,
Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 doesn't really
need to go to stable (any of 4.19, 5.4 and 5.5). While it's probably
safe, the pat
Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
On Sat, 15 Feb 2020 11:28:49 +0100
Christophe Leroy wrote:
Hi,
Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
Hi,
On Fri, 14 Feb 2020 12:47:49 + (UTC)
Christophe Leroy wrote:
When a program check exception happens while MMU tran
On 02/17/2020 10:33 AM, Anshuman Khandual wrote:
> This replaces all remaining open encodings with is_vm_hugetlb_page().
>
> Cc: Paul Mackerras
> Cc: Benjamin Herrenschmidt
> Cc: Michael Ellerman
> Cc: Alexander Viro
> Cc: Will Deacon
> Cc: "Aneesh Kumar K.V"
> Cc: Andrew Morton
> Cc: Nick
On 02/17/2020 10:33 AM, Anshuman Khandual wrote:
> Lets move vma_is_accessible() helper to include/linux/mm.h which makes it
> available for general use. While here, this replaces all remaining open
> encodings for VMA access check with vma_is_accessible().
>
> Cc: Guo Ren
> Cc: Geert Uytterhoe
On PPC32, pte_offset_map() does a kmap_atomic() in order to support
page tables allocated in high memory, just like ARM and x86/32.
But since at least 2008 and commit 8054a3428fbe ("powerpc: Remove dead
CONFIG_HIGHPTE"), page tables are never allocated in high memory.
When the page is in low mem,
On Mon, 17 Feb 2020 10:03:22 +0100
Christophe Leroy wrote:
>
>
> Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
> > On Sat, 15 Feb 2020 11:28:49 +0100
> > Christophe Leroy wrote:
> >
> >> Hi,
> >>
> >> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
> >>> Hi,
> >>>
> >>> On Fri, 14 Feb 2
https://bugzilla.kernel.org/show_bug.cgi?id=206525
--- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) ---
That's not a PPC32 bug but a Network bug affecting all 32 bits architectures.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=206525
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Component|PPC-32 |Other
Hardwa
On Sat, 2020-02-15 at 11:17 +0100, Christophe Leroy wrote:
>
> Le 15/02/2020 à 07:28, Leonardo Bras a écrit :
> > On Sun, 2020-02-09 at 18:14 +, Christophe Leroy wrote:
> > > In ITLB miss handled the line supposed to clear bits 20-23 on the
> > > L2 ITLB entry is buggy and does indeed nothing,
On Sat, 2020-02-15 at 03:49 -0300, Leonardo Bras wrote:
> Hello Christophe, thank you for the patch.
>
> On Thu, 2020-02-06 at 08:42 +, Christophe Leroy wrote:
> > Commit fa7b9a805c79 ("tools/selftest/vm: allow choosing mem size and
> > page size in map_hugetlb") added the possibility to chang
On Sat, 2020-02-15 at 03:23 -0300, Leonardo Bras wrote:
> Mahesh Salgaonkar writes:
>
> Hello Mahesh,
>
> > POWER9P PVR bits are same as that of POWER9. Hence mask off only the
> > relevant bits for the major revision similar to POWER9.
> >
> > Without this patch the cpuinfo output shows 17.0 a
On Mon, 2020-02-17 at 09:33 +1100, Michael Neuling wrote:
> On Sat, 2020-02-15 at 02:36 -0300, Leonardo Bras wrote:
> > Before checking for cpu_type == NULL, this same copy happens, so doing
> > it here will just write the same value to the t->oprofile_type
> > again.
> >
> > Remove the repeated c
Hello Christophe, thank you for the feedback.
On Mon, 2020-02-17 at 07:31 +0100, Christophe Leroy wrote:
> > if (old.oprofile_cpu_type != NULL) {
> > t->oprofile_cpu_type = old.oprofile_cpu_type;
> > - t->oprofile_type = old.oprofile_type;
> >
On 2/17/20 3:48 AM, dftxbs3e wrote:
> On 2/16/20 7:16 PM, Cédric Le Goater wrote:
>>
>> I think this is fixed by commit f55750e4e4fb ("spapr/xive: Mask the EAS when
>> allocating an IRQ") which is not in QEMU 4.1.1. The same problem should also
>> occur with LE guests.
>>
>> Could you possibly r
Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
On Mon, 17 Feb 2020 10:03:22 +0100
Christophe Leroy wrote:
Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
On Sat, 15 Feb 2020 11:28:49 +0100
Christophe Leroy wrote:
Hi,
Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
Hi,
On Fri
On 02/17/2020 03:38 PM, Christophe Leroy wrote:
Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
On Mon, 17 Feb 2020 10:03:22 +0100
Christophe Leroy wrote:
Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
On Sat, 15 Feb 2020 11:28:49 +0100
Christophe Leroy wrote:
Hi,
Le 14/02/20
I was wondering if there was history behind VDS64_HAS_DESCRIPTORS and in
what cases would one want to turn them on? (Note, I'm assuming they are
an implementation of Function Descriptors. [1])
arch/powerpc/include/asm/vdso.h unsets the macro:
/* Define if 64 bits VDSO has procedure descriptors
On Fri, 2020-02-07 at 01:38 -0300, Leonardo Bras wrote:
> > Why not make them static inline just like the generic ones ?
> >
>
> Sure, can be done. It would save some function calls.
> For that I will define the per-cpu variable in .c and declare it in .h
> All new function can be moved to .h, w
- Add a SPDX header;
- Use standard markup for document title;
- Adjust identation on lists and add blank lines where
needed;
- Add it to the powerpc index.rst file.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/powerpc/index.rst | 1 +
...ispatch_stats.txt => vcpudis
Hello John, comments inline;
On Fri, 2020-02-07 at 14:54 -0800, John Hubbard wrote:
> On 2/5/20 7:25 PM, Leonardo Bras wrote:
> > On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
> > > gup_pgd_range(addr, end, gup_flags, pages, &nr);
> > > - local_irq_enable();
On Mon, 2020-02-17 at 07:40 +0100, Christophe Leroy wrote:
>
> Le 16/02/2020 à 23:40, Michael Neuling a écrit :
> > On Fri, 2020-02-14 at 08:33 +, Christophe Leroy wrote:
> > > With CONFIG_VMAP_STACK, data MMU has to be enabled
> > > to read data on the stack.
> >
> > Can you describe what go
On Mon, 17 Feb 2020 16:38:50 +0100
Christophe Leroy wrote:
>
>
> Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
> > On Mon, 17 Feb 2020 10:03:22 +0100
> > Christophe Leroy wrote:
> >
> >>
> >>
> >> Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
> >>> On Sat, 15 Feb 2020 11:28:49 +0100
>
csky:
Acked-by: Guo Ren
On Mon, Feb 17, 2020 at 1:04 PM Anshuman Khandual
wrote:
>
> Lets move vma_is_accessible() helper to include/linux/mm.h which makes it
> available for general use. While here, this replaces all remaining open
> encodings for VMA access check with vma_is_accessible().
>
In kvmppc_unmap_free_pte() in book3s_64_mmu_radix.c, we use the
non-constant value PTE_INDEX_SIZE to clear a PTE page.
We can instead use the constant RADIX_PTE_INDEX_SIZE, because we know
this code will only be running when the Radix MMU is active.
Note that we already use RADIX_PTE_INDEX_SIZE f
Le 18/02/2020 à 01:44, Masami Hiramatsu a écrit :
On Mon, 17 Feb 2020 16:38:50 +0100
Christophe Leroy wrote:
Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
On Mon, 17 Feb 2020 10:03:22 +0100
Christophe Leroy wrote:
Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
On Sat, 15 Feb
There is a new ASRC included in i.MX serial platform, there
are some common definition can be shared with each other.
So move the common definition to a separate header file.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.h| 11 +--
sound/soc/fsl/fsl_asrc_common.h | 21 +
Add new module driver for new ASRC in i.MX8MN.
Shengjiu Wang (3):
ASoC: fsl_asrc: Move common definition to fsl_asrc_common
ASoC: dt-bindings: fsl_easrc: Add document for EASRC
ASoC: fsl_easrc: Add EASRC ASoC CPU DAI and platform drivers
changes in v2
- change i.MX815 to i.MX8MN
- Add chang
EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
IP module found on i.MX8MN.
Signed-off-by: Shengjiu Wang
---
.../devicetree/bindings/sound/fsl,easrc.txt | 57 +++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,easrc
EASRC (Enhanced Asynchronous Sample Rate Converter) is a new IP module
found on i.MX8MN. It is different with old ASRC module.
The primary features for the EASRC are as follows:
- 4 Contexts - groups of channels with an independent time base
- Fully independent and concurrent context control
- Sim
On 24/12/2019 10:32, Alexey Kardashevskiy wrote:
>
>
> On 23/12/2019 22:18, Michael Ellerman wrote:
>> Alexey Kardashevskiy writes:
>>
>>> The last jump to free_exit in mm_iommu_do_alloc() happens after page
>>> pointers in struct mm_iommu_table_group_mem_t were already converted to
>>> physi
Now the minimum allocation size for a TCE table level is PAGE_SIZE (64k)
as this is the minimum for alloc_pages(). The limit was set in POWER8
where we did not have sparse RAM so we did not need sparse TCE tables.
On POWER9 we have gaps in the phys address space for which using multi
level TCE tabl
Here is an attempt to support bigger DMA space for devices
supporting DMA masks less than 59 bits (GPUs come into mind
first). POWER9 PHBs have an option to map 2 windows at 0
and select a windows based on DMA address being below or above
4GB.
This adds the "iommu=iommu_bypass" kernel parameter
We are about to allow another location for the second DMA window and
we will need to advertise it outside of the powernv platform code.
This moves bypass base address to iommu_table_group so drivers such as
VFIO SPAPR TCE can see it.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/
This moves code to make the next patches look simpler. In particular:
1. Separate locals declaration as we will be allocating a smaller DMA
window if a TVE1_4GB option (allows a huge DMA windows at 4GB) is enabled;
2. Pass the bypass offset directly to pnv_pci_ioda2_create_table()
as it is the on
IODA2 systems (POWER8/9) allow DMA windows at 2 fixed locations - 0 and
0x800...==1<<59, stored in TVT as TVE0/1. PHB4 on POWER9 has
an additional PHB mode to allow mapping both windows at 0 and selecting
one based on IOBA address - accesses below 4GB go via TVE0 and above
4GB - via TVE
So far the only option for a big 64big DMA window was a window located
at 0x800... (1<<59) which creates problems for devices
supporting smaller DMA masks.
This exploits a POWER9 PHB option to allow the second DMA window to map
at 0 and advertises it with a 4GB offset to avoid overlap
49 matches
Mail list logo
