On 18.12.19 10:29, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_SYS_PERFMON privileged processes.
> For backward compatibility reasons access to the monitoring remains open
> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure
> monitoring is discouraged with r
Hi Dave,
On 23/01/20 12:15 am, Dave Hansen wrote:
> Still doesn't build for me:
>
I have this patch that hopefully fixes this. My understanding was
that the vm tests are supposed to be generic but this has quite a
bit of x86-specific conditional code which complicates things even
though it is no
Commit f7354ccac844 ("powerpc/32: Remove CURRENT_THREAD_INFO and
rename TI_CPU") broke the CPU wake-up from sleep mode (i.e. when
_TLF_SLEEPING is set) by delaying the tovirt(r2, r2).
This is because r2 is not restored by fast_exception_return. It used
to work (by chance ?) because CPU wake-up int
Add a new api that returns Management Complex firmware version
and make the required structure public. The api's first user will be
the caam driver for setting prediction resistance bits.
Signed-off-by: Andrei Botila
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 33 +
inc
> -Original Message-
> From: Andrei Botila
> Sent: Monday, January 27, 2020 1:16 PM
>
> Add a new api that returns Management Complex firmware version
> and make the required structure public. The api's first user will be
> the caam driver for setting prediction resistance bits.
>
> Si
This incremental patch fixes several soft-mask debug and unsafe
smp_processor_id messages due to tracing and false positives in
"unreconciled" code.
It also fixes a bug with syscall tracing functions that set registers
(e.g., PTRACE_SETREG) not setting GPRs properly.
There was a bug reported with
I've been looking at usage of per-CPU variable cpu_hw_events in
arch/powerpc/perf/core-book3s.c.
power_pmu_enable() and power_pmu_disable() (pmu::pmu_enable() and
pmu::pmu_disable()) are accessing the variable and the callbacks are
invoked always with disabled interrupts.
power_pmu_event_init() (
On 1/27/20 2:11 AM, Sandipan Das wrote:
> Hi Dave,
>
> On 23/01/20 12:15 am, Dave Hansen wrote:
>> Still doesn't build for me:
>>
> I have this patch that hopefully fixes this. My understanding was
> that the vm tests are supposed to be generic but this has quite a
> bit of x86-specific conditiona
+ Frank (me)
On 1/26/20 5:52 AM, Michael Ellerman wrote:
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms it
On Tue, Jan 28, 2020 at 12:17:12AM +1000, Nicholas Piggin wrote:
> This incremental patch fixes several soft-mask debug and unsafe
> smp_processor_id messages due to tracing and false positives in
> "unreconciled" code.
>
> It also fixes a bug with syscall tracing functions that set registers
> (e
Reorder Linux PTE bits to (almost) match Hash PTE bits.
RW Kernel : PP = 00
RO Kernel : PP = 00
RW User : PP = 01
RO User : PP = 11
So naturally, we should have
_PAGE_USER = 0x001
_PAGE_RW = 0x002
Today 0x001 and 0x002 and _PAGE_PRESENT and _PAGE_HASHPTE which
both are software only bits.
Another incremental patch which fixes silly tabort_syscall bug that
causes kernel crashes when making system calls in transactional state.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/entry_64.S | 9 +++--
arch/powerpc/kernel/syscall_64.c | 4 ++--
2 files changed, 5 insertions(+
Michal Suchánek's on January 28, 2020 4:08 am:
> On Tue, Jan 28, 2020 at 12:17:12AM +1000, Nicholas Piggin wrote:
>> This incremental patch fixes several soft-mask debug and unsafe
>> smp_processor_id messages due to tracing and false positives in
>> "unreconciled" code.
>>
>> It also fixes a bug
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.
This test covers basic page table entry
> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
> wrote:
>
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table
On 01/28/2020 07:41 AM, Qian Cai wrote:
>
>
>> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
>> wrote:
>>
>> This adds tests which will validate architecture page table helpers and
>> other accessors in their compliance with expected generic MM semantics.
>> This will help various architect
> On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
> wrote:
>
>
>
> On 01/28/2020 07:41 AM, Qian Cai wrote:
>>
>>
>>> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
>>> wrote:
>>>
>>> This adds tests which will validate architecture page table helpers and
>>> other accessors in their co
On 01/28/2020 09:03 AM, Qian Cai wrote:
>
>
>> On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
>> wrote:
>>
>>
>>
>> On 01/28/2020 07:41 AM, Qian Cai wrote:
>>>
>>>
On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
wrote:
This adds tests which will validate architecture pa
> On Jan 27, 2020, at 11:58 PM, Anshuman Khandual
> wrote:
>
> As I had mentioned before, the test attempts to formalize page table helper
> semantics
> as expected from generic MM code paths and intend to catch deviations when
> enabled on
> a given platform. How else should we test semant
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 operations. Make perf_event_paranoid_check()
and __cmd_ftrace() to be aware of CAP_PERFMON capability.
CAP_PERFMON implements the
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
Le 28/01/2020 à 04:33, Qian Cai a écrit :
On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
wrote:
On 01/28/2020 07:41 AM, Qian Cai wrote:
On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
wrote:
This adds tests which will validate architecture page table helpers and
other accessors
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
Le 28/01/2020 à 06:48, Qian Cai a écrit :
On Jan 27, 2020, at 11:58 PM, Anshuman Khandual
wrote:
As I had mentioned before, the test attempts to formalize page table helper
semantics
as expected from generic MM code paths and intend to catch deviations when
enabled on
a given platform.
> On Jan 28, 2020, at 1:17 AM, Christophe Leroy wrote:
>
> It is 'default y' so there is no much risk that it is forgotten, at least all
> test suites run with 'allyes_defconfig' will trigger the test, so I think it
> is really a good feature.
This thing depends on DEBUG_VM which I don’t se
On 01/28/2020 12:06 PM, Qian Cai wrote:
>
>
>> On Jan 28, 2020, at 1:17 AM, Christophe Leroy
>> wrote:
>>
>> It is 'default y' so there is no much risk that it is forgotten, at least
>> all test suites run with 'allyes_defconfig' will trigger the test, so I
>> think it is really a good fea
> On Jan 28, 2020, at 2:03 AM, Anshuman Khandual
> wrote:
>
> 'allyesconfig' makes 'DEBUG_VM = y' which in turn will enable
> 'DEBUG_VM_PGTABLE = y'
> on platforms that subscribe ARCH_HAS_DEBUG_VM_PGTABLE.
Isn’t that only for compiling testing? Who is booting such a beast and make
sure eve
> On Jan 28, 2020, at 1:13 AM, Christophe Leroy wrote:
>
> ppc32 an indecent / legacy platform ? Are you kidying ?
>
> Powerquicc II PRO for instance is fully supported by the manufacturer and
> widely used in many small networking devices.
Of course I forgot about embedded devices. The pro
36 matches
Mail list logo
