* Kees Cook wrote:
> Switch to using the newly created asm-generic/seccomp.h for the
> seccomp strict mode syscall definitions. The obsolete sigreturn
> syscall override is retained in 32-bit mode, and the ia32 syscall
> overrides are used in the compat case. Remaining definitions were
> ide
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig | 6 +
drivers/soc/fsl/fman/Makefile | 7 +-
drivers/soc/fsl/fman/mac/Makefile | 15 +
drivers/soc/fsl/fman/mac/fman_crc32.c | 117
drivers/soc/fsl/fm
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig | 10 +
drivers/soc/fsl/fman/Makefile |2 +
drivers/soc/fsl/fman/port/Makefile| 13 +
drivers/soc/fsl/fman/port/fman_port.c | 1536 +
4 files changed, 1
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/Kconfig |1 +
drivers/soc/Makefile |1 +
drivers/soc/fsl/Kconfig |1 +
drivers/soc/fsl/Makefile |1 +
drivers/soc/fsl/fman/Kconfig |7 +
drivers/soc/fsl/fman/Makefile | 13 +
dr
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig| 6 +
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/pcd/Makefile | 13 +
drivers/soc/fsl/fman/pcd/fman_kg.c | 850
drivers/soc/fsl/fman/pcd/fm
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/sp/Makefile | 13 +++
drivers/soc/fsl/fman/sp/fman_sp.c | 204 ++
3 files changed, 218 insertions(+)
create mode 100644 drivers/soc/fsl/fma
From: Igal Liberman
Signed-off-by: Igal Liberman
---
drivers/soc/fsl/fman/Kconfig| 6 +
drivers/soc/fsl/fman/Makefile | 1 +
drivers/soc/fsl/fman/rtc/Makefile | 13 ++
drivers/soc/fsl/fman/rtc/fman_rtc.c | 354
4 files changed, 374 inser
From: Igal Liberman
The Freescale Data Path Acceleration Architecture (DPAA) is a set of
hardware components on specific QorIQ P and T series multicore processors.
This architecture provides the infrastructure to support simplified
sharing of networking interfaces and accelerators by multiple CPU
According to i.MX6 Series Reference Manual, the formula to calculate
the sys clock is
sysclk rate = bclk rate * (div2 + 1) * (7 * psr + 1) * (pm + 1) * 2
Commit aafa85e71a75 ("ASoC: fsl_ssi: Add DAI master mode support for
SSI on i.MX series") added the divisor calculation which relies on
the clk
The /sys/kernel/mobility/migration interface was added all the way back
in 2.6.37. However, the drmgr userspace tool was never augmented to use
this interface to perfrom migrations. Instead it has continued using a
faux rtas call coupled with performing the device tree update processing
in userspac
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. The obsolete sigreturn syscall override
is retained in 32-bit mode, and the ia32 syscall overrides are used in
the compat case. Remaining definitions were identical.
Signed-off-by: Kees Cook
-
Most architectures don't need to do much special for the strict-mode
seccomp syscall entries. Remove the redundant headers and reduce the
others.
Signed-off-by: Kees Cook
---
v3:
- split patch series by architecture
- fix up architectures that need sigreturn overrides (ingo)
v2:
- use Kbuild "gen
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. Definitions were identical.
Signed-off-by: Kees Cook
---
arch/parisc/include/asm/Kbuild| 1 +
arch/parisc/include/asm/seccomp.h | 16
2 files changed, 1 insertion(+), 16
Some architectures may need to override the compat sigreturn definition,
as is already possible in the non-compat case.
Signed-off-by: Kees Cook
---
include/asm-generic/seccomp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
i
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. The obsolete sigreturn in COMPAT mode
is retained as an override. Remaining definitions are identical, though
they incorrectly appeared in uapi, which has been corrected.
Signed-off-by: Kees Co
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. COMPAT definitions retain their overrides
and the remaining definitions were identical.
Signed-off-by: Kees Cook
---
arch/mips/include/asm/seccomp.h | 7 ++-
1 file changed, 2 insertions(
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. The obsolete sigreturn in COMPAT mode
is retained as an override. Remaining definitions are identical. Also
corrected missing #define for header reinclusion protection.
Signed-off-by: Kees Cook
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. Since microblaze is 32-bit, the COMPAT
seccomp defines are unused and can be dropped. The obsolete sigreturn
for seccomp strict mode is retained as an override. Remaining definitions
are identic
Switch to using the newly created asm-generic/seccomp.h for the seccomp
strict mode syscall definitions. Definitions were identical.
Signed-off-by: Kees Cook
---
arch/arm/include/asm/Kbuild| 1 +
arch/arm/include/asm/seccomp.h | 11 ---
2 files changed, 1 insertion(+), 11 deletions(
On Fri, 2015-02-27 at 10:02 -0600, Kumar Gala wrote:
> On Jan 20, 2015, at 6:03 AM, Igal.Liberman
> wrote:
> > + guts_regs = of_iomap(guts, 0);
> > + of_node_put(guts);
> > + if (!guts_regs) {
> > + pr_err("ioremap of GUTS node failed\n");
> > + return -EINVAL;
> > + }
On Wed, 2015-03-04 at 13:13 -0800, Kees Cook wrote:
>
> I had a question in the powerpc-specific change that may have gone unnoticed:
>
> Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs
> use "mm->mmap_base = TASK_UNMAPPED_BASE + random_factor".
>
> Separate from this s
On Wed, 2015-03-04 at 07:46 -0400, Julian Margetson wrote:
> Still stuck.
> Problem still exist with 4.0.0-rc2 and I cant finish the bisect.
> Triggered when using HDMI. No problem when using DVI.
> [ 33.535692] Unable to handle kernel paging request for data at address
> 0x0008
> [ 33.56
In preparation for moving ET_DYN randomization into the ELF loader (which
requires a static ELF_ET_DYN_BASE), this redefines s390's existing ET_DYN
randomization in a call to arch_mmap_rnd(). This refactoring results in
the same ET_DYN randomization on s390.
Signed-off-by: Kees Cook
---
arch/s39
This fixes the "offset2lib" weakness in ASLR for arm, arm64, mips,
powerpc, and x86. The problem is that if there is a leak of ASLR from
the executable (ET_DYN), it means a leak of shared library offset as
well (mmap), and vice versa. Further details and a PoC of this attack
is available here:
http
On Wed, Mar 4, 2015 at 1:54 PM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
>> ASLR from mmap ASLR, as already done on s390. The architectures
>> that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
>> and x86),
* Kees Cook wrote:
> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
> ASLR from mmap ASLR, as already done on s390. The architectures
> that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
> and x86), have their various forms of arch_mmap_rnd() made available
To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
ASLR from mmap ASLR, as already done on s390. The architectures
that are already randomizing mmap (arm, arm64, mips, powerpc, s390,
and x86), have their various forms of arch_mmap_rnd() made available
via the new CONFIG_ARCH_HAS_EL
When an architecture fully supports randomizing the ELF load location,
a per-arch mmap_rnd() function is used to find a randomized mmap base.
In preparation for randomizing the location of ET_DYN binaries
separately from mmap, this renames and exports these functions as
arch_mmap_rnd(). Additionall
In preparation for splitting out ET_DYN ASLR, this moves the ASLR calculations
for mmap on ARM into a separate routine, similar to x86. This also removes
the redundant check of personality (PF_RANDOMIZE is already set before calling
arch_pick_mmap_layout).
Signed-off-by: Kees Cook
---
arch/arm/m
On Tue, Mar 3, 2015 at 8:16 PM, Michael Ellerman wrote:
> On Mon, 2015-03-02 at 16:19 -0800, Kees Cook wrote:
>> This fixes the "offset2lib" weakness in ASLR for arm, arm64, mips,
>> powerpc, and x86. The problem is that if there is a leak of ASLR from
>> the executable (ET_DYN), it means a leak o
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86.
Signed-off-by: Kees Cook
Acked-by: Michael Ellerman
---
Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs
use "mm->mmap_base = TASK_UNMAPPED_BASE + rand
The arch_randomize_brk() function is used on several architectures,
even those that don't support ET_DYN ASLR. To avoid bulky extern/#define
tricks, consolidate the support under CONFIG_ARCH_HAS_ELF_RANDOMIZE for
the architectures that support it, while still handling CONFIG_COMPAT_BRK.
Signed-off
In preparation for splitting out ET_DYN ASLR, extract the mmap ASLR
selection into a separate function.
Signed-off-by: Kees Cook
---
It seems the entropy gets smaller as the PAGE_SIZE increases. Is this
intentional?
---
arch/mips/mm/mmap.c | 24
1 file changed, 16 insert
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86. This additionally enables
mmap ASLR on legacy mmap layouts, which appeared to be missing on arm64,
and was already supported on arm. Additionally removes a copy/pasted
declaration
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm and x86, and extracts the checking
of PF_RANDOMIZE.
Signed-off-by: Kees Cook
---
arch/s390/mm/mmap.c | 34 +++---
1 file changed, 23 insertions(+), 11 deleti
In preparation for splitting out ET_DYN ASLR, this refactors the use of
mmap_rnd() to be used similarly to arm, and extracts the checking of
PF_RANDOMIZE.
Signed-off-by: Kees Cook
---
arch/x86/mm/mmap.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
During suspend/migration operation we must wait for the VASI state reported
by the hypervisor to become Suspending prior to making the ibm,suspend-me
RTAS call. Calling routines to rtas_ibm_supend_me() pass a vasi_state variable
that exposes the VASI state to the caller. This is unnecessary as the
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands is not endian safe as it relies
on parsing buffers returned by RTAS calls that thusly contains data in
On Wed, 2015-03-04 at 00:44 -0600, Jia Hongtao-B38951 wrote:
> Hi Scott,
>
> I sent V3 of this patch a few days ago.
> Comments are welcome.
Patience is welcome. :-)
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
On 03/03/2015 02:16 PM, Tyrel Datwyler wrote:
> On 03/02/2015 10:15 PM, Michael Ellerman wrote:
>> On Mon, 2015-03-02 at 13:30 -0800, Tyrel Datwyler wrote:
>>> On 03/01/2015 08:19 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
> During suspend/migration opera
Ok, I'm fine dropping this patch. I'm sure it doesn't affect
performance in a measurable way.
mh
On Tue, Mar 3, 2015 at 7:35 PM, Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:35 -0500
> Martin Hicks wrote:
>
>> The submission count was off by one.
>>
>> Signed-off-by: Martin Hicks
>> ---
>
On Wednesday, March 04, 2015 12:56:20 PM Geert Uytterhoeven wrote:
> If CONFIG_SMP=n, does not include , causing:
>
> drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
> drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of
> function 'get_hard_
Still stuck.
Problem still exist with 4.0.0-rc2 and I cant finish the bisect.
Triggered when using HDMI. No problem when using DVI.
[ 33.535692] Unable to handle kernel paging request for data at address
0x0008
[ 33.566786] Faulting instruction address: 0xc049db84
[ 33.574188] Vector:
If CONFIG_SMP=n, does not include , causing:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of
function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]
Signed-off-by: Gee
On Sun, Mar 01, 2015 at 07:30:35PM +0100, Markus Stockhausen wrote:
> This is the assembler code for the MD5 implementation.
> Handling of algorithm constants has been slightly
> changed to reduce register usage and make better use
> of cores with multiple ALUs. Thus they are stored as
> delta valu
The 24x7 counters in Powerpc allow monitoring a large number of counters
simultaneously. They also allow reading several counters in a single
HCALL so we can get a more consistent snapshot of the system.
Use the PMU's transaction interface to monitor and read several event
counters at once. The id
perf_event_read() does two things:
- call the PMU to read/update the counter value
- and compute the total count of the event and its children
perf_event_reset() needs the first piece but doesn't need the second.
Similarly, when we implement the ability to read a group of events
perf_event_read_value() reads the counter from the PMC and computes the
total count (including child events). Add an 'update' parameter and have
it read the PMC only if 'update' parameter is TRUE (which it always is
for now). When we add support for reading multiple events using the
transaction int
In addition to using the transaction interface to schedule events
on a PMU, we will use it to also read a group of counters at once.
Accordingly, add a flags parameter to the transaction interfaces.
The flags indicate wheether the transaction is to add events to
the PMU (PERF_PMU_TXN_ADD) or to rea
Unlike normal hardware PMCs, the 24x7 counters[1] in Power8 are stored in
memory and accessed via a hypervisor call (HCALL). A major aspect of the
HCALL is that it allows retireving _SEVERAL_ counters at once (unlike
regular PMCs, which are read one at a time). By reading several counters
at once,
On 02/06/2015 01:06 AM, Hari Bathini wrote:
This patch adds a new PPC64 partition type to be used for opal
specific nvram partition. A new partition type is needed as none
of the existing type matches this partition type.
Signed-off-by: Hari Bathini
This patch series is reviewed by Kees.
Refe
Le 03/03/2015 19:44, Mark Brown a écrit :
On Thu, Feb 26, 2015 at 05:11:42PM +0100, Christophe Leroy wrote:
On CPM2, the SPI parameter RAM is dynamically allocated in the dualport RAM
whereas in CPM1, it is statically allocated to a default address with
capability to relocate it somewhere else v
52 matches
Mail list logo