.
__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:
It
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 header
On 14/02/2019 13:28, Peter Zijlstra wrote:
On Thu, Feb 14, 2019 at 12:41:32AM +0200, Igor Stoppa wrote:
[...]
+#define wr_rcu_assign_pointer(p, v) ({ \
+ smp_mb(); \
+ wr_assign(p, v);\
+ p; \
+})
This
write-rare path.
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.openwal
.
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
since the granularity
available for write protection is of one memory page.
The functionality is automatically activated by any architecture that sets
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: D
address for the alternate map across the entire
available address range from user space (128TB - 64TB)
* convert BUG() 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
* doc
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
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
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
.
__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
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
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
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
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
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
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, but
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 dele
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 bei
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 chang
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/o
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 chang
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 chang
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 chang
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 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 out
-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
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Inaky Perez-Gonzalez
---
drivers/net/wimax/i2400m/tx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wimax/i2400m/tx.c b/drivers/net/
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Mike Snitzer
Cc: Alasdair Kergon
---
drivers/md/dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 20f7e4e
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa
Cc: Kees Cook
---
kernel/seccomp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index fd023ac24e10..5a2a9af
The condition to test is unlikely() to be true. Add the hint.
Signed-off-by: Igor Stoppa
Cc: "Michael S. Tsirkin"
---
tools/virtio/linux/kernel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
index fb
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Larry Finger
Cc: Kalle Valo
---
drivers/net/wireless/broadcom/b43/dma.c | 2 +-
drivers/net/wireless/broadcom/b43legacy/dma.c | 2 +-
2 files changed, 2 inser
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
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/o
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: zijun_hu
Cc: Tejun Heo
Cc: Christoph Lameter
Cc: Dennis Zhou
---
mm/percpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/percpu.c b/mm/per
Typically the assert is expected to not fail.
Signed-off-by: Igor Stoppa
Cc: Chien Tung
Cc: Roland Dreier
Cc: Faisal Latif
Cc: Doug Ledford
Cc: Jason Gunthorpe
---
drivers/infiniband/hw/nes/nes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/nes
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
---
arch/mips/include/asm/bug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/
The assert() condition is likely to be true.
Signed-off-by: Igor Stoppa
Cc: huangdaode
Cc: Yisen Zhuang
Cc: Salil Mehta
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
b/drivers/net
WARN_ON_ONCE() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Kalle Valo
Cc: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wir
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa
Cc: Rob Clark
Cc: David Airlie
Cc: Archit Taneja
Cc: Stephane Viau
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp_format.c| 2
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Andrew Jeffery
Cc: Linus Walleij
---
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/a
WARN_ON_ONCE() already contains an unlikely(), and the logical or of two of
them is still unlikely(), so it's not necessary to wrap them into another.
Signed-off-by: Igor Stoppa
Cc: Christian Lamparter
Cc: Kalle Valo
---
drivers/net/wireless/ath/carl9170/tx.c | 4 ++--
1 file chang
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().
Signed-off-by: Igor Stoppa
Cc: Arnd Bergmann
---
include/asm-generic/bug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic
BUG_ON() is unlikely() to BUG()
Signed-off-by: Igor Stoppa
Cc: Dmitry Safonov
Cc: Shuah Khan
---
tools/testing/selftests/vm/map_populate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/map_populate.c
b/tools/testing/selftests/vm/map_populate.c
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Alexander Viro
---
fs/open.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/open.c b/fs/open.c
index 0285ce7dbd51..19a9e4b378d3 100644
--- a/fs/o
Both WARN_ON() and WARN_ONCE() already contain an unlikely(), so it's not
necessary to wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/driver
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Bart Van Assche
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/dr
WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.
Signed-off-by: Igor Stoppa
Cc: Arseny Solokha
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/mm/tlb_nohash.c | 2 +-
arch/powerpc/sysdev/xive/common.c | 2
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-sm
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/cpuf
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 chang
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/infiniban
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 that
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
Ping?
The kernel test automation seems to confirm my findings:
https://marc.info/?l=linux-mm&m=151999308428656&w=2
Is this really a bug?
On 22/02/18 16:13, Igor Stoppa wrote:
> While trying to change the code of find_vm_area, I got an automated
> notification that my code wa
arent area.
This will avoid more expensive searches, later on.
Signed-off-by: Igor Stoppa
Reviewed-by: Jay Freyensee
Reviewed-by: Matthew Wilcox
---
include/linux/mm_types.h | 1 +
mm/vmalloc.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/linux/mm_types.h b/inc
Detailed documentation about the protectable memory allocator.
Signed-off-by: Igor Stoppa
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 161 +
2 files changed, 162 insertions(+)
create mode 100644 Documentation/core-api
available for modifying the memory, which is also mapped at a random
address, which is harder to retrieve, even in case of another core
racing with the one performing the modification.
Signed-off-by: Igor Stoppa
CC: Carlos Chinea Perez
CC: Remi Denis Courmont
---
Documentation/core-api
Try to alter locked but modifiable pools.
The test neds some cleanup and expansion.
It is provided primarily as reference.
Signed-off-by: Igor Stoppa
---
mm/test_pmalloc.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/mm
Verify that pmalloc read-only protection is in place: trying to
overwrite a protected variable will crash the kernel.
Signed-off-by: Igor Stoppa
---
drivers/misc/lkdtm/core.c | 3 +++
drivers/misc/lkdtm/lkdtm.h | 1 +
drivers/misc/lkdtm/perms.c | 25 +
3 files changed
shows how to deny an
easy target to the attacker.
In case the kernel is compiled with JOP safeguards, then it becomes far
harder for the attacker to jump into the middle of the function which
calls pmalloc_rare_write, to alter the state.
Signed-off-by: Igor Stoppa
---
security/selinu
tilization outside of the purging phase.
Since the purging happens after the vmap_area is dismissed, its use is
mutually exclusive with any use performed while the area is allocated.
Signed-off-by: Igor Stoppa
---
include/linux/vmalloc.h | 2 +-
mm/vmalloc.c| 6 +++---
2 files changed, 4
Add basic self-test functionality for pmalloc.
The testing is introduced as early as possible, right after the main
dependency, genalloc, has passed successfully, so that it can help
diagnosing failures in pmalloc users.
Signed-off-by: Igor Stoppa
---
include/linux/test_pmalloc.h | 24
tect one of hte internal states
of SELinux.
Changes since v22:
[http://www.openwall.com/lists/kernel-hardening/2018/04/13/3]
- refactored some helper functions in a separate local header
- expanded the documentation
- introduction of rare write support
- example with SELinux "initialized&quo
page,
where present.
Signed-off-by: Igor Stoppa
---
include/linux/pmalloc.h | 148
include/linux/vmalloc.h | 3 +
mm/Kconfig | 6 ++
mm/Makefile | 1 +
mm/pmalloc.c
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data
On 24/04/18 16:32, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d and destroy the old pool.
With the above, you have just shifted the target of the arbitrary write
from
On 24/04/18 16:49, Stephen Smalley wrote:
On 04/23/2018 08:54 AM, Igor Stoppa wrote:
[...]
The patch is probably in need of rework, to make it fit better with the
new SELinux internal data structures, however it shows how to deny an
easy target to the attacker.
I know this is just an
On 24/04/18 19:03, lazytyped wrote:
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d a
On 14/03/18 19:33, Matthew Wilcox wrote:
> I think an implementation of
> pmalloc which used a page_frag-style allocator would be larger than
> 100 lines, but I don't think it would have to be significantly larger
> than that.
I have some doubt about what is the best way to implement it using
vmal
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data
On 04/05/18 01:55, Dave Hansen wrote:
On 05/03/2018 02:52 PM, Igor Stoppa wrote:
At the end of the summit, we agreed that I would go through the physmap.
Do you mean the kernel linear map?
Apparently I did mean it. It was confusing, because I couldn't find a
single place stati
On 14/03/18 19:43, J Freyensee wrote:
> On 3/13/18 3:00 PM, Matthew Wilcox wrote:
[...]
>>> Signed-off-by: Igor Stoppa
>> Reviewed-by: Matthew Wilcox
>
> Igor, do you mind sticking these tags on the files that have spent some
> time reviewing a revision of your pat
On 14/03/2018 19:33, Matthew Wilcox wrote:
> On Wed, Mar 14, 2018 at 06:11:22PM +0200, Igor Stoppa wrote:
[...]
>> Probably page_frag does well with relatively large allocations, while
>> genalloc seems to be better for small (few allocation units) allocations.
>
> I don
The GFP bitmasks and the __GFP_BITS_SHIFT defines are expressed as
hardcoded constants.
This can be expressed in a more consistent way by relying on an enum of
shift positions.
Igor Stoppa (1):
Remove hardcoding of ___GFP_xxx bitmasks
include/linux/gfp.h | 82
The bitmasks used for ___GFP_xxx can be defined in terms of an enum,
which doesn't require manual updates to its values.
As bonus, __GFP_BITS_SHIFT is automatically kept consistent.
Signed-off-by: Igor Stoppa
---
include/linux/gfp.h | 82 +++
On 26/04/17 17:47, Michal Hocko wrote:
> On Wed 26-04-17 16:35:49, Igor Stoppa wrote:
>> The bitmasks used for ___GFP_xxx can be defined in terms of an enum,
>> which doesn't require manual updates to its values.
>
> GFP masks are rarely updated so why is this wort
On 26/04/17 18:29, Igor Stoppa wrote:
> On 26/04/17 17:47, Michal Hocko wrote:
[...]
>> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed
>> here so I suspect you have based your change on the Linus tree.
> I used your tree from kernel.org
I found it,
On 26/04/17 18:29, Igor Stoppa wrote:
> On 26/04/17 17:47, Michal Hocko wrote:
[...]
>> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed
>> here so I suspect you have based your change on the Linus tree.
> I used your tree from kernel.org
I found it,
On 27/04/17 16:41, Michal Hocko wrote:
> On Wed 26-04-17 18:29:08, Igor Stoppa wrote:
> [...]
>> If you prefer to have this patch only as part of the larger patchset,
>> I'm also fine with it.
>
> I agree that the situation is not ideal. If a larger set of chan
On 28/04/17 10:40, Michal Hocko wrote:
> Do not add a new zone, really. What you seem to be looking for is an
> allocator on top of the page/memblock allocator which does write
> protection on top. I understand that you would like to avoid object
> management duplication but I am not really sure
On 27/04/17 18:06, Michal Hocko wrote:
> On Tue 25-04-17 12:42:57, Joonsoo Kim wrote:
[...]
>> Yes, it requires one more bit for a new zone and it's handled by the patch.
>
> I am pretty sure that you are aware that consuming new page flag bits
> is usually a no-go and something we try to avoid
On 28/04/17 10:43, Igor Stoppa wrote:
[...]
> I'm writing an alternative different proposal, let's call it last attempt.
>
> Should be ready in a few minutes.
Here: http://marc.info/?l=linux-mm&m=149336675129967&w=2
--
thanks, igor
s, but I have not completed the
whole conversion.
> On Fri 28-04-17 11:04:27, Igor Stoppa wrote:
> [...]
>> * if one is happy to have a 64bits type, allow for as many zones as
>> it's possible to fit, or anyway more than what is possible with
>> the 32 bit mask.
going away, according to Casey.
Note:
The patch is larg-ish, but I was not sure what criteria to use for
splitting it.
If it helps the reviewing, please do let me know how I should split it
and I will comply.
Igor Stoppa (2):
Protectable memory support
Make LSM Writable Hooks a command line opti
From: Igor Stoppa
The MMU available in many systems running Linux can often provide R/O
protection to the memory pages it handles.
However, the MMU-based protection works efficiently only when said pages
contain exclusively data that will not need further modifications.
Statically allocated
result of introducing an enum, security_hook_heads becomes a local
variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
rename security_hook_heads to hook_heads.
Signed-off-by: Tetsuo Handa
Rebased-by: Igor Stoppa
Cc: Kees Cook
Cc: Paul Moore
Cc: Stephen Smalley
Cc: Case
From: Igor Stoppa
This patch shows how it is possible to take advantage of pmalloc:
instead of using the build-time option __lsm_ro_after_init, to decide if
it is possible to keep the hooks modifiable, now this becomes a
boot-time decision, based on the kernel command line.
This patch relies on
201 - 300 of 461 matches
Mail list logo
