BUG_ON() already contains an unlikely(), there is no need for another one.
Signed-off-by: Igor Stoppa
Cc: "Martin K. Petersen"
Cc: "James E.J. Bottomley"
---
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Joe Thornber
Cc: Alasdair Kergon
---
drivers/md/dm-cache-policy-smq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-cache-policy-smq.c b
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa
Cc: "Rafael J. Wysocki"
Cc: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/c
Typically the assert is expected to not fail.
Signed-off-by: Igor Stoppa
Acked-by: Doug Ledford
Cc: Faisal Latif
Cc: Chien Tung
Cc: Roland Dreier
Cc: Faisal Latif
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
drivers/infiniband/hw/nes/nes.h | 2
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Acked-by: Dennis Zhou
Cc: Tejun Heo
Cc: zijun_hu
Cc: Christoph Lameter
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/percpu.c | 2 +-
1 file changed, 1
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Reviewed-by: Bart Van Assche
Cc: linux-r...@vger.kernel.org (open list:SCSI RDMA PROTOCOL (SRP) TARGET)
Cc: linux-kernel@vger.kernel.org (open list)
---
drivers/infiniband/ulp
On 31/08/18 17:09, Arnd Bergmann wrote:
[...]
#define assert(condition)
...
if (unlikely(!(condition)))
error_action()
...
There is a potential that this introduces false-postive -Wmaybe-uninitialized
warnings when CONFIG_PROFILE_ANNOTATED_BRANCHES is
set, since
BUG_ON() is unlikely() to BUG()
For unlikely(), borrow the definition from tools/include/linux/compiler.h
Signed-off-by: Igor Stoppa
Cc: Dmitry Safonov
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
tools/testing/selftests/vm/map_populate.c | 6
Hi Dmitry,
On 31/08/18 02:04, Dmitry Safonov wrote:
Probably, the one from "tools/include/linux/compiler.h" can be used in
tools directory.
Thank you for the advice. It seems to work now.
--
igor
() to WARN()
* turn verification of written data into debugging option
* wr_rcu_assign_pointer() as special case of wr_assign()
* example with protection of ima_policy_flags
* documentation
Igor Stoppa (12):
__wr_after_init: Core and default arch
__wr_after_init: x86_64: memset_user()
__wr
The write protection of the __wr_after_init data can be verified with the
same methodology used for const data.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
code to privide a
memset_user() function, which is currently missing.
clear_user() is the base for memset_user()
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
code to privide a
memset_user() function, which is currently missing.
clear_user() is the base for memset_user()
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
Set ARCH_HAS_PRMEM to Y for arm64
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC: linux-integr...@vger.kernel.org
CC: kernel-harden...@lists.openwall.com
CC: linux
Set ARCH_HAS_PRMEM to Y for x86_64
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
Update the self-protection documentation, to mention also the use of the
__wr_after_init attribute.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed
Refactor the test cases, in preparation for using them also for testing
__wr_after_init memory, when available.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
.
__wr_after_init can still provide some protection, at least against
simple memory overwrite attacks
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
Set of test cases meant to confirm that the write rare functionality
works as expected.
It can be optionally compiled as module.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago
.
This is accomplished by providing arch-specific version of the function
__init_wr_base()
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC: linux
Verify that trying to modify a variable with the __wr_after_init
attribute will cause a crash.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC
On 12/02/2019 02:09, Kees Cook wrote:
On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa wrote:
[...]
Patch-set implementing write-rare memory protection for statically
allocated data.
It seems like this could be expanded in the future to cover dynamic
memory too (i.e. just a separate base
On 12/02/2019 03:26, Kees Cook wrote:
On Mon, Feb 11, 2019 at 5:08 PM igor.sto...@gmail.com
wrote:
On Tue, 12 Feb 2019, 4.47 Kees Cook
On Mon, Feb 11, 2019 at 4:37 PM Igor Stoppa wrote:
On 12/02/2019 02:09, Kees Cook wrote:
On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa wrote
On 12/02/2019 04:39, Matthew Wilcox wrote:
On Tue, Feb 12, 2019 at 01:27:38AM +0200, Igor Stoppa wrote:
+#ifndef CONFIG_PRMEM
[...]
+#else
+
+#include
It's a mistake to do conditional includes like this. That way you see
include loops with some configs and not others. Our headers
On 15/02/2019 10:57, Peter Zijlstra wrote:
Where are the comments and Changelog notes ? How is an arch maintainer
to be aware of this requirement when adding support for his/her arch?
Yes, it will be fixed in the next revision. I've added comment to the
core wr_assign function and also to
Refactor the test cases, in preparation for using them also for testing
__wr_after_init memory.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
://www.openwall.com/lists/kernel-hardening/2018/11/22/8
[2] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1793199.html
[3] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1810245.html
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel-harden...@lists.openwall.com
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
include/asm-generic/vml
, in a preemptible
system, however the amount of data to be altered is likely to be far
smaller than a page.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
The write protection of the __wr_after_init data can be verified with the
same methodology used for const data.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel
Set of test cases meant to confirm that the write rare functionality
works as expected.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
Verify that trying to modify a variable with the __wr_after_init
modifier wil lcause a crash.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: linux-integr...@vger.kernel.org
CC: kernel-harden
On 19/12/2018 23:33, Igor Stoppa wrote:
+ if (WARN_ONCE(op >= WR_OPS_NUMBER, "Invalid WR operation.") ||
+ WARN_ONCE(!is_wr_after_init(dst, len), "Invalid WR range."))
+ return (void *)dst;
+
+ offset = dst - (unsigned long)&__star
Hi,
On 20/12/2018 19:20, Thiago Jung Bauermann wrote:
Hello Igor,
+/*
+ * The following two variables are statically allocated by the linker
+ * script at the the boundaries of the memory region (rounded up to
+ * multiples of PAGE_SIZE) reserved for __wr_after_init.
+ */
+extern long
Hi,
On 20/12/2018 19:30, Thiago Jung Bauermann wrote:
Hello Igor,
Igor Stoppa writes:
diff --git a/security/integrity/ima/ima_init.c
b/security/integrity/ima/ima_init.c
index 59d834219cd6..5f4e13e671bf 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
On 20/12/2018 20:49, Matthew Wilcox wrote:
I think you're causing yourself more headaches by implementing this "op"
function.
I probably misinterpreted the initial criticism on my first patchset,
about duplication. Somehow, I'm still thinking to the endgame of having
higher-level
On 21/12/2018 19:23, Andy Lutomirski wrote:
On Thu, Dec 20, 2018 at 11:19 AM Igor Stoppa wrote:
On 20/12/2018 20:49, Matthew Wilcox wrote:
I think you're causing yourself more headaches by implementing this "op"
function.
I probably misinterpreted the initial criticism o
, in a preemptible
system, however the amount of data to be altered is likely to be far
smaller than a page.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed
Create x86_64 specific version of memset for user space, based on
clear_user().
This will be used for implementing wr_memset() in the __wr_after_init
scenario, where write-rare variables have an alternate mapping for
writing.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC
of memset()
- wr_memcpy(): write rare counterpart of memcpy()
- wr_assign(): write rare counterpart of the assignment ('=') operator
- wr_rcu_assign_pointer(): write rare counterpart of rcu_assign_pointer()
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter
Refactor the test cases, in preparation for using them also for testing
__wr_after_init memory, when available.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
Update the self-protection documentation, to mention also the use of the
__wr_after_init attribute.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed
o activate both section and label, the arch must set CONFIG_ARCH_HAS_PRMEM
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC: linux-integr...@vger.
To avoid code duplication, re-use __memset_user(), when clearing
user-space memory.
The overhead should be minimal (2 extra register assignments) and
outside of the writing loop.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees
The write protection of the __wr_after_init data can be verified with the
same methodology used for const data.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC
Verify that trying to modify a variable with the __wr_after_init
attribute will cause a crash.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC
Set of test cases meant to confirm that the write rare functionality
works as expected.
It can be optionally compiled as module.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago
.
__wr_after_init can still provide some protection, at least against
simple memory overwrite attacks
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
After each write operation, confirm that it was successful, otherwise
generate a warning.
Signed-off-by: Igor Stoppa
CC: Andy Lutomirski
CC: Nadav Amit
CC: Matthew Wilcox
CC: Peter Zijlstra
CC: Kees Cook
CC: Dave Hansen
CC: Mimi Zohar
CC: Thiago Jung Bauermann
CC: Ahmed Soliman
CC
On 21/12/2018 20:25, Matthew Wilcox wrote:
On Fri, Dec 21, 2018 at 08:14:12PM +0200, Igor Stoppa wrote:
+unsigned long __memset_user(void __user *addr, int c, unsigned long size)
+{
+ long __d0;
+ unsigned long pattern = 0;
+ int i;
+
+ for (i = 0; i < 8
On 21/12/2018 20:41, Matthew Wilcox wrote:
On Fri, Dec 21, 2018 at 08:14:14PM +0200, Igor Stoppa wrote:
+static inline int memtst(void *p, int c, __kernel_size_t len)
I don't understand why you're verifying that writes actually happen
in production code. Sure, write lib/test_wrmem.c
On 21/12/2018 21:43, Matthew Wilcox wrote:
On Fri, Dec 21, 2018 at 09:07:54PM +0200, Igor Stoppa wrote:
On 21/12/2018 20:41, Matthew Wilcox wrote:
On Fri, Dec 21, 2018 at 08:14:14PM +0200, Igor Stoppa wrote:
+static inline int memtst(void *p, int c, __kernel_size_t len)
I don't
On 21/12/2018 21:45, Matthew Wilcox wrote:
On Fri, Dec 21, 2018 at 11:38:16AM -0800, Nadav Amit wrote:
On Dec 19, 2018, at 1:33 PM, Igor Stoppa wrote:
+static inline void *wr_memset(void *p, int c, __kernel_size_t len)
+{
+ return __wr_op((unsigned long)p, (unsigned long)c, len
On 06/12/2018 01:13, Andy Lutomirski wrote:
+ kasan_disable_current();
+ if (op == WR_MEMCPY)
+ memcpy((void *)wr_poking_addr, (void *)src, len);
+ else if (op == WR_MEMSET)
+ memset((u8 *)wr_poking_addr, (u8)src, len);
+ else if (op ==
On 06/12/2018 06:44, Matthew Wilcox wrote:
On Tue, Dec 04, 2018 at 02:18:01PM +0200, Igor Stoppa wrote:
+void *__wr_op(unsigned long dst, unsigned long src, __kernel_size_t len,
+ enum wr_op_type op)
+{
+ temporary_mm_state_t prev;
+ unsigned long flags
On 06/12/2018 11:44, Peter Zijlstra wrote:
On Wed, Dec 05, 2018 at 03:13:56PM -0800, Andy Lutomirski wrote:
+ if (op == WR_MEMCPY)
+ memcpy((void *)wr_poking_addr, (void *)src, len);
+ else if (op == WR_MEMSET)
+ memset((u8 *)wr_poking_addr, (u8)src,
On 06/09/18 01:23, Kees Cook wrote:
Should I take this, or is it part of your series going somewhere else?
It turned out it doesn't really work to have a generic series against 20
trees :-/
I'm submitting them individually to each subsystem.
So this one is just for security.
--
thanks,
On 07/09/18 18:13, Doug Ledford wrote:
This patch was part of a larger series on lkml. In that context, I
acked it so that the series could be applied by whomever took it (it
didn't belong on rdma-list as a series since only one patch out of some
large number touched rdma files). Now it is
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa
Cc: Srivatsa S. Bhat
Cc: "Rafael J. Wysocki"
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
fs/open.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/open.c
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Aaro Koskinen
Cc: Greg Kroah-Hartman
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
1 file changed, 1
Add a hint to the compiler that probably it won't be necessary to BUG()
Signed-off-by: Igor Stoppa
Cc: David Daney
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
arch/mips/include/asm/bug.h | 2 +-
1 file changed, 1
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Acked-by: Dennis Zhou
Cc: Tejun Heo
Cc: zijun_hu
Cc: Christoph Lameter
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
mm/percpu.c | 2 +-
1 file changed, 1
Add a hint to the compiler.
If BUG_ON() is used instead of BUG(), it means that probably the
preferred outcome is to not BUG().
The optimization is disabled, in case CONFIG_PROFILE_ANNOTATED_BRANCHES
is turned on.
Signed-off-by: Igor Stoppa
Cc: Arnd Bergmann
Cc: linux-a...@vger.kernel.org
Cc
On 07/09/18 21:39, Dennis Zhou wrote:
Sorry for the delay. I'll be taking over the percpu tree and am in the
process of getting a tree. I'm still keeping track of this and will take
it for the next release.
ok, np!
--
thank you, igor
On 07/09/18 23:41, Arnd Bergmann wrote:
Could you add a comment about -Wmaybe-uninitialized next to the definition?
Otherwise that is easily lost.
Also, I see that the file has two separate definitions of BUG_ON(), and the
other one does have an unlikely() in it already. Can you change both
-uninitialized.
Signed-off-by: Igor Stoppa
Cc: Arnd Bergmann
Cc: linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/asm-generic/bug.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 20561a60db9c
Hi Paul,
On 08/09/18 01:02, Paul Burton wrote:
I'm not sure this will actually do anything.
__BUG_ON() doesn't use the value of its condition argument for regular
control flow unless it's compile-time constant anyway, in which case
unlikely() should be redundant because the compiler knows the
On 05/09/18 09:01, Leon Romanovsky wrote:
On Fri, Aug 31, 2018 at 10:24:18PM +0300, Igor Stoppa wrote:
Typically the assert is expected to not fail.
This whole assert can be removed.
ok
Signed-off-by: Igor Stoppa
Acked-by: Doug Ledford
Most probably that I missed discussion
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa
Acked-by: Kees Cook
Cc: linux-security-mod...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
kernel/seccomp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
On 10/09/18 15:16, Arnd Bergmann wrote:
Acked-by: Arnd Bergmann
I assume this will be included in a longer patch series rather than
going through
my asm-generic tree, right?
sadly, no: this patch is just for the asm-generic tree
I tried with the longer patch series, but it didn't work
-uninitialized.
Signed-off-by: Igor Stoppa
Acked-by: Arnd Bergmann
Cc: linux-a...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/asm-generic/bug.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 20561a60db9c
On 01/11/2018 01:19, Andy Lutomirski wrote:
ISTM you don't need that atomic operation -- you could take a spinlock
and then just add one directly to the variable.
It was my intention to provide a 1:1 conversion of existing code, as it
should be easier to verify the correctness of the
started, and there is not alternate, writable
mapping to exploit.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC: "Kirill A. Shutemov"
CC: Andrew Morton
CC: Pavel Tatashin
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
MAINTAINERS | 7 +
doubly linked list for tracking the chain of
vmap_areas, only one pointer is spent for this purpose, in a single
linked list, while the other is used to provide a direct connection to the
parent pool.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Andrew Morton
CC: Chintan Pandya
CC: Joe Perches
Wrappers around the basic write rare functionality, addressing several
common data types found in the kernel, allowing to specify the new
values through immediates, like constants and defines.
Note:
The list is not complete and could be expanded.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC
-off-by: Igor Stoppa
CC: Kees Cook
CC: Greg Kroah-Hartman
CC: Arnd Bergmann
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
drivers/misc/lkdtm/core.c | 13 ++
drivers/misc/lkdtm/lkdtm.h | 13 ++
drivers/misc/lkdtm/perms.c | 248 +
3 files changed
.
It shouldn't be anyway a big loss, in terms of security: with only two
fields, there is a 50% chance of guessing correctly the layout.
The randomization is disabled only when write rare is enabled.
Signed-off-by: Igor Stoppa
CC: Kees Cook
CC: Greg Kroah-Hartman
CC: Andrew Morton
CC: Masahiro
The measurement list is moved to write rare memory, including
related data structures.
Various boilerplate linux data structures and related functions are
replaced by their write-rare counterpart.
Signed-off-by: Igor Stoppa
CC: Mimi Zohar
CC: Dmitry Kasatkin
CC: James Morris
CC: "Se
Minimalistic functionality for having the write rare version of
atomic_long_t data.
Signed-off-by: Igor Stoppa
CC: Will Deacon
CC: Peter Zijlstra
CC: Boqun Feng
CC: Arnd Bergmann
CC: linux-a...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
MAINTAINERS | 1
These test cases focus on the basic operations required to operate
both prlist and prhlist data, in particular creating, growing, shrinking,
destroying.
They can also be useful as reference for practical use of write-rare lists.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: Philippe
the direct reference
from struct page.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC: "Kirill A. Shutemov"
CC: Andrew Morton
CC: Pavel Tatashin
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
include/linux/mm_types.h | 25 ++--
-off-by: Igor Stoppa
CC: Greg Kroah-Hartman
CC: Andrew Morton
CC: Masahiro Yamada
CC: Alexey Dobriyan
CC: Pekka Enberg
CC: "Paul E. McKenney"
CC: Lihao Liang
CC: linux-kernel@vger.kernel.org
---
include/linux/types.h | 20
1 file changed, 16 insertions(+), 4
to functions that can perform write rare.
Since lists are one of the most commonly used data structures in kernel,
they are a the first candidate for receiving write rare extensions.
This patch implements basic functionality for altering said lists.
Signed-off-by: Igor Stoppa
CC: Thomas Gleixner
CC
Prevent leaks of protected memory to userspace.
The protection from overwrited from userspace is already available, once
the memory is write protected.
Signed-off-by: Igor Stoppa
CC: Kees Cook
CC: Chris von Recklinghausen
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
include
Using a list_head in an unnamed union poses a problem with the current
implementation of the initializer, since it doesn't specify the names of
the fields it is initializing.
This patch makes it use designated initializers.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: "David S. Miller
The test cases verify the various interfaces offered by both prmem.h and
prmemextra.h
The tests avoid triggering crashes, by not performing actions that would
be treated as illegal. That part is handled in the lkdtm patch.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC
he current write-rare mechanism works
only on x86_64 and not arm64, due to arm64 mappings.
Signed-off-by: Igor Stoppa
CC: Arnd Bergmann
CC: Thomas Gleixner
CC: Kate Stewart
CC: Greg Kroah-Hartman
CC: Philippe Ombredanne
CC: linux-a...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
include/a
the memory that was obtained from it is
automatically freed. This is the only way to release protected memory.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC: "Kirill A. Shutemov"
CC: Andrew Morton
CC: Pavel Tatashin
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.or
On 24/10/18 14:37, Mathieu Desnoyers wrote:
I could not find a description of the overall context of this patch
(e.g. a patch 00/17 ?) that would explain the attack vectors this aims
to protect against.
Apologies, I have to admit I was a bit baffled about what to do: the
patchset spans
Hi,
On 24/10/18 06:27, Randy Dunlap wrote:
a. It seems backwards (or upside down) to have a test case select a feature
(PRMEM)
instead of depending on that feature.
b. Since PRMEM depends on MMU (in patch 04/17), the "select" here could try to
enabled PRMEM even when MMU is not enabled.
On 24/10/2018 17:56, Tycho Andersen wrote:
On Wed, Oct 24, 2018 at 05:03:01PM +0300, Igor Stoppa wrote:
On 24/10/18 14:37, Mathieu Desnoyers wrote:
Also, is it the right approach to duplicate existing APIs, or should we
rather hook into page fault handlers and let the kernel do those "s
On 24/10/2018 06:12, Matthew Wilcox wrote:
On Wed, Oct 24, 2018 at 12:34:55AM +0300, Igor Stoppa wrote:
The connection between each page and its vmap_area avoids more expensive
searches through the btree of vmap_areas.
Typo -- it's an rbtree.
ack
+++ b/include/linux/mm_types.h
Hi,
I have the following fragment of code:
+struct my_struct {
+ atomic_long_t l __aligned(sizeof(atomic_long_t));
+} __aligned(sizeof(atomic_long_t));
triggering this warning, when fed to checkpatch.pl:
WARNING: function definition argument 'atomic_long_t' should also have
an
On 30/05/17 13:32, James Morris wrote:
> This seems like pointless churn in security-critical code in anticipation
> of features which are still in development and may not be adopted.
>
> Is there a compelling reason to merge this now? (And I don't mean worrying
> about non-existent
On 28/05/17 21:23, Kees Cook wrote:
> On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa wrote:
[...]
>> If the CPU1 were to forcibly halt anything that can race with it, then
>> it would be sure that there was no interference.
>
> Correct. This is actually what ARM does fo
On 04/05/17 14:21, Michal Hocko wrote:
> On Wed 03-05-17 15:06:36, Igor Stoppa wrote:
[...]
>> * In most, if not all, the cases that could be enhanced, the code will
>> be calling kmalloc/vmalloc, indicating GFP_KERNEL as the desired type of
>> memory.
>
> Ho
On 04/05/17 16:11, Michal Hocko wrote:
> On Thu 04-05-17 15:14:10, Igor Stoppa wrote:
> I believe that this is a fundamental question. Sealing sounds useful
> for after-boot usecases as well and it would change the approach
> considerably. Coming up with an ad-hoc solution for the b
On 04/05/17 17:30, Dave Hansen wrote:
> On 05/04/2017 01:17 AM, Igor Stoppa wrote:
>> Or, let me put it differently: my goal is to not fracture more pages
>> than needed.
>> It will probably require some profiling to figure out what is the
>> ballpark of the memory f
701 - 800 of 850 matches
Mail list logo
