.
This is mainly intended for the dynamic linker,
which sets up the address space on behalf of
dynamic binaries. By using this flag, it can
prevent exploited code from remapping read-only
executable code or data sections read-write.
Signed-off-by: Ard Biesheuvel ard.biesheu...@gmail.com
---
arch/alpha
2012/10/4 Kees Cook keesc...@chromium.org:
On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton a...@linux-foundation.org
wrote:
Again: has this proposal been reviewed by the glibc maintainers? If
so, what was their position on it?
Ard have you talked with them? I would expect it would be
2012/10/4 Mikael Pettersson mi...@it.uu.se:
- If .text is mapped non-writable and final, how would a debugger
(or any ptrace-using monitor-like application) plant a large
number of breakpoints in a target process? Breakpoint registers
aren't enough because (a) they're few in number, and
2012/10/4 PaX Team pagee...@freemail.hu:
Thanks for taking a look at this matter.
This is mainly intended for the dynamic linker,
which sets up the address space on behalf of
dynamic binaries. By using this flag, it can
prevent exploited code from remapping read-only
executable code or
2012/10/6 PaX Team pagee...@freemail.hu:
sadly, this is not true at all, for multiple reasons:
.. snip ...
cheers,
PaX Team
So can I summarize your position as that there is no merit at all in
the ability to inhibit future permissions of existing mappings?
--
Ard.
--
To unsubscribe from
.
This is mainly intended for the dynamic linker,
which sets up the address space on behalf of
dynamic binaries. By using this flag, it can
prevent exploited code from remapping read-only
executable code or data sections read-write.
Signed-off-by: Ard Biesheuvel ard.biesheu...@gmail.com
---
arch/powerpc
This seems like a good idea to me. It would allow more than just the
loader to harden userspace allocations. It's a more direct version of
PaX's MPROTECT feature[1]. That feature hardens existing loaders,
but doesn't play nice with JITs (like Java), but this lets a loader
(or JIT) opt-in to
2012/10/2 Kees Cook keesc...@chromium.org:
If desired, additional restrictions can be imposed by using the
security framework, e.g,, disallow non-final r-x mappings.
Interesting; what kind of interface did you have in mind?
The 'interface' we use is a LSM .ko which registers handlers for
Only x86 implements arch_cpu_uevent(), and there is nothing arch
specific about it, so move it to drivers/base/cpu.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 11 ---
drivers/base/cpu.c | 15 ++-
include/linux/cpu.h
This enables the generic implementation in drivers/base/cpu.c
that allows modules to be loaded automatically based on the
optional features supported (and advertised) by the CPU.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig| 3 +++
arch/arm64/kernel
This implements the changes needed to turn CPU features
declared as being depended upon by modules into module aliases
in the .ko metadata.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
include/linux/mod_devicetable.h | 11 +++
scripts/mod/devicetable-offsets.c | 3
.)
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
drivers/base/cpu.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 49c6f4b..a661d31 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -276,6 +276,30
in question would be loaded automatically if
a NEON-capable CPU is detected (and advertised).
Ard Biesheuvel (4):
x86: move arch_cpu_uevent() to generic code
cpu: advertise CPU features over udev in a generic way
scripts/mod: add generic CPU features as module alias
arm64: advertise CPU features
On 7 nov. 2013, at 20:33, Dave Martin dave.mar...@arm.com wrote:
On Thu, Nov 07, 2013 at 06:17:35PM +0100, Ard Biesheuvel wrote:
This patch implements a generic modalias 'cpu:feature:...' which
enables CPU feature flag based module loading in a generic way.
All the arch needs to do
On 7 November 2013 20:33, Dave Martin dave.mar...@arm.com wrote:
On Thu, Nov 07, 2013 at 06:17:35PM +0100, Ard Biesheuvel wrote:
This patch implements a generic modalias 'cpu:feature:...' which
enables CPU feature flag based module loading in a generic way.
All the arch needs to do is enable
On 7 November 2013 22:39, Andi Kleen a...@linux.intel.com wrote:
On Thu, Nov 07, 2013 at 01:09:41PM -0800, H. Peter Anvin wrote:
On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
This series implements automatic module loading based on optional CPU
features,
and tries to do so in a generic
This is a known issue that will hopefully be sorted shortly:
http://marc.info/?l=linux-arm-kernelm=138515869216723w=2
--
Ard.
On 23 November 2013 20:13, Guenter Roeck li...@roeck-us.net wrote:
On 11/23/2013 10:51 AM, Geert Uytterhoeven wrote:
On Sat, Nov 23, 2013 at 7:40 PM, Guenter Roeck
be performed
on IA-64 in the first place.
If I could get acks for this patch please (if there are no
objections), I will propose it to be merged through the ARM and/or
arm64 trees as part of the complete series to enable SMBIOS.
Regards,
Ard.
On 21 November 2013 12:40, Ard Biesheuvel ard.biesheu
On 27 November 2013 13:22, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, Nov 27, 2013 at 12:12 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Mon, 25 Nov 2013 13:07:23 +0100, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
Hello all,
Resending this patch to a slightly wider
into hardcoded physical address
0xF to be disabled.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
Changes since v1:
- followed Grant's suggestion to use a Kconfig symbol in conjunction with
IS_ENABLED() rather than a plain #ifdef to en-/disable the dmi scan fallback
arch
Only x86 implements arch_cpu_uevent(), and there is nothing arch
specific about it, so move it to drivers/base/cpu.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 11 ---
drivers/base/cpu.c | 15 ++-
include/linux/cpu.h
and alias GCC attribute foo
Ard Biesheuvel (4):
x86: move arch_cpu_uevent() to generic code
cpu: advertise CPU features over udev in a generic way
x86: align with generic cpu modalias
arm64: advertise CPU features for modalias matching
arch/arm64/Kconfig| 3 +++
arch/arm64
they depend on with MODULE_DEVICE_TABLE(cpu, ...)
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
include/linux/mod_devicetable.h | 11 +++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 24 insertions(+)
diff --git
Align with the new generic 'cpu:type:...:features:...' modalias
by moving the 'x86' prefix and the vendor/family/model IDs into
the 'type' field.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 3 +--
scripts/mod/file2alias.c| 10 +-
2 files
This enables the generic implementation in drivers/base/cpu.c
that allows modules to be loaded automatically based on the
optional features supported (and advertised over udev) by the
CPU.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig| 3 +++
arch/arm64
On 14 November 2013 16:29, Catalin Marinas catalin.mari...@arm.com wrote:
On Mon, Nov 11, 2013 at 10:19:35AM +, Ard Biesheuvel wrote:
+ssize_t arch_print_cpu_modalias(struct device *dev,
+ struct device_attribute *attr,
+ char *buf
On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
operates similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is
Ping?
On 8 February 2014 13:34, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
This series implements a generic way to wire up udev module autoprobing to
optional CPU features.
Patch #1 implements the actual generic part. It relies on the include file
asm/cpufeature.h to be supplied
On 16 February 2014 17:39, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Sun, Feb 16, 2014 at 03:40:04PM +0100, Ard Biesheuvel wrote:
Ping?
Sorry, still digging out from the -rc1 backlog. Give me a few days,
Monday is a holliday in the US.
Yes, please, whenever you have
On 5 February 2014 14:37, Catalin Marinas catalin.mari...@arm.com wrote:
On Thu, Jan 23, 2014 at 03:01:23PM +, Catalin Marinas wrote:
On Fri, Jan 17, 2014 at 09:23:06AM +, Ard Biesheuvel wrote:
Ard Biesheuvel (5):
ARM: add support for AT_HWCAP2 ELF auxv entry
binfmt_elf: add
On 5 September 2013 14:45, Will Deacon will.dea...@arm.com wrote:
Hi Jean,
[adding Michael, since I know he was interested in this]
On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote:
On ARM the debug info is not present in the .eh_frame sections but
instead in .debug_frame.
Use
On 5 September 2013 15:05, Jean Pihet jean.pi...@newoldbits.com wrote:
[..]
Here are the commands I have been using:
perf record -g dwarf -- binary to profile
perf report --sort symbol --call-graph --stdio
Ah, I failed to add the 'dwarf' after -g, however, in that case, my
perf report
On 4 September 2013 20:04, Jean Pihet jean.pi...@linaro.org wrote:
From: Will Deacon will.dea...@arm.com
This patch implements the functions required for the perf refs API,
'regs API' not 'refs API'
Regards,
Ard.
allowing the perf tool to interface kernel register dumps with libunwind
in
to Ubuntu Saucy's libunwind8
on a Ubuntu Raring system (Calxeda Highbank)
FWIW, for the series
Tested-by: Ard Biesheuvel ard.biesheu...@linaro.org # on
ARM/Highbank/UbuntuSaucy
--
Ard.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 7 sep. 2013, at 04:44, Josh Boyer jwbo...@fedoraproject.org wrote:
We enabled CONFIG_KERNEL_MODE_NEON on the armv7hl builds we're doing.
It builds for a while, but eventually fails when running modpost on
the xor.ko module:
ERROR: xor_block_neon_inner [crypto/xor.ko] undefined!
On 7 May 2014 00:42, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Fri, Apr 11, 2014 at 09:48:42PM +0200, Ard Biesheuvel wrote:
On 11 April 2014 18:03, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote
enabling it for arm64:
http://marc.info/?l=linux-arm-kernelm=139101486308822w=2
Example using it (optional AES instructions on arm64):
http://marc.info/?l=linux-arm-kernelm=139101446008665w=2
Best regards,
Ard.
On 29 January 2014 17:50, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
This patch
On 5 February 2014 18:04, Leif Lindholm leif.lindh...@linaro.org wrote:
From: Ard Biesheuvel ard.biesheu...@linaro.org
Loading unauthenticated FDT blobs directly from storage is a security hazard,
so this should only be allowed when running with UEFI Secure Boot disabled.
Signed-off-by: Ard
On 20 January 2014 18:44, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 20 Jan 2014, Catalin Marinas wrote:
On Mon, Dec 23, 2013 at 02:06:27PM +, Ard Biesheuvel wrote:
This series is a followup to the patch that was recently merged by Catalin
that
allocates hwcaps bits
On 20 January 2014 19:17, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
On 20 January 2014 18:44, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 20 Jan 2014, Catalin Marinas wrote:
On Mon, Dec 23, 2013 at 02:06:27PM +, Ard Biesheuvel
On 20 January 2014 19:55, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
On 20 January 2014 19:17, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
Calling getauxval(AT_HWCAP) on an outdated libc.so will give
on EFI
Fix by changing the 'select EFI' to a 'depends on EFI'.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
drivers/firmware/google/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/firmware/google/Kconfig b/drivers/firmware/google/Kconfig
index
On 23 January 2014 22:40, Mike Waychison mi...@google.com wrote:
On Thu, Jan 23, 2014 at 1:36 PM, David Rientjes rient...@google.com wrote:
On Thu, 23 Jan 2014, Ard Biesheuvel wrote:
The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI. This
causes problems on other archs when
Align with the new generic 'cpu:type:...:features:...' modalias
by moving the 'x86' prefix and the vendor/family/model IDs into
the 'type' field.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 3 +--
scripts/mod/file2alias.c| 10 +-
2 files
@Russell, Nico,
Care to share your opinion on this alternative approach to allocating
hwcap feature bits for the ARMv8 Crypto Extensions for 32-bit ARM?
Regards,
Ard.
On 23 December 2013 15:06, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
This series is a followup to the patch
On 15 January 2014 03:16, Roy Franz roy.fr...@linaro.org wrote:
On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz roy.fr...@linaro.org wrote:
On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
This patch
This adds support for advertising the presence of ARMv8 Crypto
Extensions in the Aarch32 execution state to 32-bit ELF binaries
running in 32-bit compat mode under the arm64 kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/hwcap.h | 6 ++
arch/arm64
Add ELF_HWCAP2 to the set of auxv entries that is passed to
a 32-bit ELF program running in 32-bit compat mode under a
64-bit kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
fs/compat_binfmt_elf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/compat_binfmt_elf.c
This enables AT_HWCAP2 for ARM. The generic support for this
new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
Add HWCAP2 aux entry)
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm/include/asm/hwcap.h | 3 ++-
arch/arm/include/uapi/asm/hwcap.h | 4
Add support for the ELF auxv entry AT_HWCAP2 when running 32-bit
ELF binaries in compat mode.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/hwcap.h | 3 ++-
arch/arm64/kernel/setup.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC
extensions introduced in ARMv8.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm/include/uapi/asm/hwcap.h | 5 +
arch/arm/kernel/setup.c | 5 +
2 files changed, 10 insertions(+)
diff --git
only hardware (such as ARMv8-R)
Patch #5 advertises the CRC and Crypto Extensions to 32-bit ELF binaries running
under an arm64 kernel.
v2 changes:
- omitted 2 arm64 specific patches that have already been merged by Catalin
- move ARM feature bits to HWCAP2
Ard Biesheuvel (5):
ARM: add support
On 17 January 2014 16:07, Will Deacon will.dea...@arm.com wrote:
Hi Ard,
On Fri, Jan 17, 2014 at 09:23:07AM +, Ard Biesheuvel wrote:
This enables AT_HWCAP2 for ARM. The generic support for this
new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
Add HWCAP2 aux entry)
Does
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: Andrzej Pietrasiewicz andrze...@samsung.com
---
Documentation/ABI/testing/configfs-usb-gadget | 12 ++--
Documentation/ABI/testing/configfs-usb-gadget-acm | 2 +-
Documentation/ABI/testing/configfs-usb
features both internally and to user space.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/cpufeature.h | 30 ++
2 files changed, 31 insertions(+)
create mode 100644 arch/arm64/include/asm
Only x86 implements arch_cpu_uevent(), and there is nothing arch
specific about it, so move it to drivers/base/cpu.c and rename
it to cpu_uevent().
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 11 ---
drivers/base/cpu.c | 15
crypto module to the optional AES
feature found on arm64.
Ard Biesheuvel (5):
cpu: move arch_cpu_uevent() to generic code
cpu: add generic support for CPU feature based module autoloading
x86: align x86 arch with generic CPU modalias handling
arm64: enable generic CPU feature modalias matching
,venfammod:feature:,,' instead of
the 'x86cpu:vendor::family::model::feature,,' that was
used before.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/Kconfig | 4 +---
arch/x86/include/asm/cpufeature.h | 7 +++
arch/x86
This implements the core AES cipher using the Crypto Extensions,
using only NEON registers q0 and q1.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Makefile | 1 +
arch/arm64/crypto/Makefile| 13 +
arch/arm64/crypto/aes-ce-cipher.c | 103
/cpufeature.h which defines how the
numbers used in the modalias string map to actual CPU features.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
drivers/base/Kconfig | 8 ++
drivers/base/cpu.c| 39 +
include/linux/cpufeature.h
On 30 January 2014 19:56, Will Deacon will.dea...@arm.com wrote:
Hi Ard,
On Wed, Jan 29, 2014 at 04:50:46PM +, Ard Biesheuvel wrote:
diff --git a/arch/arm64/crypto/aes-ce-cipher.c
b/arch/arm64/crypto/aes-ce-cipher.c
new file mode 100644
index ..b5a5d5d6e4b8
--- /dev/null
(arm64: Add hwcaps for crypto and CRC32
extensions.) which is already in Catalin's tree and in linux-next.
Ard Biesheuvel (8):
arm64: add kernel emulation for AES instructions
x86: move arch_cpu_uevent() to generic code
cpu: advertise CPU features over udev in a generic way
x86: align
This implements the core AES cipher using the Crypto Extensions,
using only NEON registers q0 and q1.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Makefile | 1 +
arch/arm64/crypto/Makefile| 13 +
arch/arm64/crypto/aes-ce-cipher.c | 112
Only x86 implements arch_cpu_uevent(), and there is nothing arch
specific about it, so move it to drivers/base/cpu.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/kernel/cpu/match.c | 11 ---
drivers/base/cpu.c | 15 ++-
include/linux/cpu.h
-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/fpsimd.h | 3 ++
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/kernel/entry.S| 2 +-
arch/arm64/kernel/fpsimd.c | 79 +++-
arch/arm64/kernel/process.c
. To mark the end of such a partial section, the
regular kernel_neon_end() should be used.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/fpsimd.h | 17 ++
arch/arm64/include/asm/fpsimdmacros.h | 37 ++
arch/arm64/include
This enables the generic implementation in drivers/base/cpu.c
that allows modules to be loaded automatically based on the
optional features supported (and advertised over udev) by the
CPU.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig| 3 +++
arch/arm64
they depend on with MODULE_DEVICE_TABLE(cpu, ...)
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
include/linux/mod_devicetable.h | 15 +++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 28 insertions(+)
diff --git
NOTE: this patch is not intended for merging upstream, but is only
included as a bonus so mere mortals (i.e., those whose ARMv8 system
does not support the AES crypto instructions) can test the series
if they like.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Makefile
: sparse: cast to
restricted __be64
To: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: linux-cry...@vger.kernel.org linux-cry...@vger.kernel.org,
kbuild test robot fengguang...@intel.com
On Tue, Apr 01, 2014 at 02:37:20PM +0200, Ard Biesheuvel wrote:
On 1 April 2014 13:23, kbuild test robot fengguang
On 11 April 2014 18:03, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Fri, Apr 04, 2014 at 10:11:19AM +0200, Ard Biesheuvel wrote:
Greg,
This pertains to commit 8ceee72808d1 (crypto: ghash-clmulni-intel -
use C implementation for setkey()) that has been pulled by Linus
On 2 April 2014 13:04, Dan Carpenter dan.carpen...@oracle.com wrote:
This patch is still needed in linux-next. It was Acked by Tony Prisk in
a private email.
Acked-by: Tony Prisk li...@prisktech.co.nz
regards,
dan carpenter
On Mon, Aug 26, 2013 at 07:02:33PM +0300, Dan Carpenter wrote:
corruption is
high while the likelihood of immediate detection is low, e.g., when
using the NEON unit in kernel mode on arm64.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
include/linux/preempt.h | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff
places, i.e.,
after _edata.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: rost...@goodmis.org
Cc: dipan...@in.ibm.com
Cc: paul...@linux.vnet.ibm.com
---
kernel/rcu/tree.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
On 11 July 2014 17:30, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 11 Jul 2014 08:12:40 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Fri, Jul 11, 2014 at 01:38:12PM +0200, Ard Biesheuvel wrote:
Commit f7f7bac9cb1c (rcu: Have the RCU tracepoints use
On 11 July 2014 17:40, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 11 July 2014 17:30, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 11 Jul 2014 08:12:40 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Fri, Jul 11, 2014 at 01:38:12PM +0200, Ard Biesheuvel wrote
places, i.e.,
after _edata.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: rost...@goodmis.org
Cc: paul...@linux.vnet.ibm.com
---
v2:
- s/DEFINE_TPS/DEFINE_RCU_TPS/
kernel/rcu/tree.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b
On 18 July 2014 23:22, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
Nicolas Pitre nicolas.pi...@linaro.org wrote:
Here's the patch I have at the head of the series now, with the above
ugliness changed to an unconditional __tracepoint_string attribute.
On 19 July 2014 22:28, Steven Rostedt rost...@goodmis.org wrote:
On Sat, 19 Jul 2014 21:10:37 +0200
Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 18 July 2014 23:22, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
Nicolas Pitre nicolas.pi
On 30 June 2014 15:14, Andreas Schwab sch...@suse.de wrote:
This fixes the following build failure:
CC [M] arch/arm64/crypto/aes-glue-ce.o
ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory
scripts/Makefile.build:393: recipe for target
On 30 June 2014 15:56, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
Out of curiosity, how did you trigger this failure? I have build this
code numerous times (and so have others) and I have never seen this
failure.
Did you ever start with a clean
places, i.e.,
after _edata.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: rost...@goodmis.org
Cc: paul...@linux.vnet.ibm.com
---
v3:
- make definition of var_varname conditional as well
v2:
- s/DEFINE_TPS/DEFINE_RCU_TPS/
kernel/rcu/tree.c | 15 ---
1 file changed, 12
This adds support for advertising the presence of ARMv8 Crypto
Extensions in the Aarch32 execution state to 32-bit ELF binaries
running in 32-bit compat mode under the arm64 kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/hwcap.h | 6 ++
arch/arm64
This enables AT_HWCAP2 for ARM. The generic support for this
new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
Add HWCAP2 aux entry)
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm/include/asm/hwcap.h | 3 ++-
arch/arm/include/uapi/asm/hwcap.h | 4
This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC
extensions introduced in ARMv8.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm/include/uapi/asm/hwcap.h | 5 +
arch/arm/kernel/setup.c | 5 +
2 files changed, 10 insertions(+)
diff --git
Add ELF_HWCAP2 to the set of auxv entries that is passed to
a 32-bit ELF program running in 32-bit compat mode under a
64-bit kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
fs/compat_binfmt_elf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/compat_binfmt_elf.c
Add support for the ELF auxv entry AT_HWCAP2 when running 32-bit
ELF binaries in compat mode.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/hwcap.h | 3 ++-
arch/arm64/kernel/setup.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
only hardware (such as ARMv8-R)
Patch #5 advertises the CRC and Crypto Extensions to 32-bit ELF binaries running
under an arm64 kernel.
v2 changes:
- omitted 2 arm64 specific patches that have already been merged by Catalin
- move ARM feature bits to HWCAP2
Ard Biesheuvel (5):
ARM: add support
Commit 2171364d1a92 (powerpc: Add HWCAP2 aux entry) introduced a new
AT_ auxv entry type AT_HWCAP2 but failed to update AT_VECTOR_SIZE_BASE
accordingly.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Fixes: 2171364d1a92 (powerpc: Add HWCAP2 aux entry)
Cc: sta...@vger.kernel.org
) in saved_auxv[] in mm_struct.
--
Ard.
Acks, people?
Linus
On Mon, Dec 23, 2013 at 9:49 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
Commit 2171364d1a92 (powerpc: Add HWCAP2 aux entry) introduced a new
AT_ auxv entry type AT_HWCAP2 but failed to update AT_VECTOR_SIZE_BASE
code with the newly introduced generic code is done
in patch #2
- add more elaborate commit message for patch #1
- added hpa's ack on patch #2
Ard Biesheuvel (2):
cpu: add generic support for CPU feature based module autoloading
x86: align x86 arch with generic CPU modalias handling
arch/x86
,venfammod:feature:,,' instead of
the 'x86cpu:vendor::family::model::feature:,,' that was
used before.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Acked-by: H. Peter Anvin h...@linux.intel.com
---
arch/x86/Kconfig | 4 +---
arch/x86
is advertised over udev, and will only allow the module to be
loaded by hand if the 'FEAT_X' feature is supported.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
drivers/base/Kconfig | 8 ++
drivers/base/cpu.c| 50
include
On 27 July 2014 20:40, Sam Ravnborg s...@ravnborg.org wrote:
Btw. the current solution is already faulty - even with the fix.
There are no support for make C=2 arch/.../crypto/
So can you elaborate on how it is faulty?
When you run make C=2 arch/.../crypto/ then sparse shall be run
for
dereferencing it?
Updating data by blocks * SHA256_BLOCK_SIZE at the end of
ha2_finup is redundant code and can be removed.
^^^ typo here
Signed-off-by: Colin Ian King colin.k...@canonical.com
Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/crypto/sha2-ce-glue.c | 1 -
1 file
-by: byungchul.park byungchul.p...@lge.com
Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/entry-fpsimd.S |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/entry-fpsimd.S
b/arch/arm64/kernel/entry-fpsimd.S
index d358cca..c44a82f 100644
On 24 July 2014 14:29, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
On 30 June 2014 15:56, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
Out of curiosity, how did you trigger this failure? I have build
On 24 July 2014 14:35, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 24 July 2014 14:29, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
On 30 June 2014 15:56, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes
On 24 July 2014 15:26, Andreas Schwab sch...@suse.de wrote:
You are not using CONFIG_MODVERSIONS.
I am
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 24 July 2014 15:40, Andreas Schwab sch...@suse.de wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
On 24 July 2014 15:26, Andreas Schwab sch...@suse.de wrote:
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to
create
1 - 100 of 5027 matches
Mail list logo
