From: Jeff Xu
Add sysmap_is_sealed.c to test system mappings are sealed.
Note: CONFIG_MSEAL_SYSTEM_MAPPINGS must be set, as indicated in
config file.
Signed-off-by: Jeff Xu
Reviewed-by: Lorenzo Stoakes
---
tools/testing/selftests/Makefile | 1 +
.../mseal_system_mappings/.giti
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
Reviewed-by: Lorenzo Stoakes
Reviewed-by: Liam R. Howlett
---
Documentation/userspace-api/mseal.rst | 20
1 file changed, 20 inserti
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Test was done with perf tool, and observe the upr
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
Reviewed-by: Lorenzo Stoakes
Reviewed-by: Liam R. Howlett
Reviewe
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
Reviewed-by: Lorenzo Stoakes
Reviewed-by: Liam R. Howlett
Reviewed-by: Kees Cook
---
arch/x86/K
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
Reviewed-by: Lorenzo Stoakes
Reviewed-by: Liam R. Howlett
---
.../testing/selftests/x86/test_mremap_vdso.c | 43 +++
1 file changed, 43 inser
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
include/linux/mm.h | 10 ++
From: Jeff Xu
This is V9 version, addressing comments from V8, without code logic
change.
---
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a given virtual memory range against modifications, such
as
From: Jeff Xu
Add sysmap_is_sealed.c to test system mappings are sealed.
Note: CONFIG_MSEAL_SYSTEM_MAPPINGS must be set, as indicated in
config file.
Signed-off-by: Jeff Xu
---
.../mseal_system_mappings/.gitignore | 2 +
.../selftests/mseal_system_mappings/Makefile | 6 +
.../se
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
Documentation/userspace-api/mseal.rst | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Test was done with perf tool, and observe the upr
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 12
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 7 ---
2 files changed, 5 ins
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
Reviewed-by: Lorenzo Stoakes
---
.../testing/selftests/x86/test_mremap_vdso.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/t
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu
---
include/linux/mm.h | 10 ++
init/Kconfig | 22
From: Jeff Xu
This is V8 version, addressing comments from V7, without code logic
change.
---
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a given virtual memory range against modifications, such
as
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 22
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
Documentation/userspace-api/mseal.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
b/Documentation
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
the vdso.
Testing passes on UML.
Signed-off-by: Jeff Xu
Tested-by: Benjamin Berg
---
arch/um/Kconfig| 1 +
arch/x86/um/vdso/vma.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Signed-off-by: Jeff Xu
---
kernel/events/uprobe
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 16 ++--
2 files cha
From: Jeff Xu
This is V7 version, addressing comments from V6, without code logic
change.
--
History:
V7:
- Remove cover letter from the first patch (Liam R. Howlett)
- Change macro name to VM_SEALED_SYSMAP (Liam R. Howlett)
- logging and fclos
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu
---
include/linux/mm.h | 10 ++
init/Kconfig | 18 +
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
.../testing/selftests/x86/test_mremap_vdso.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/testing/selftests/x86/test_mrem
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/mseal.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
b/Documentation/userspace-api/mseal.rst
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Signed-off-by: Jeff Xu
---
kernel/events/uprobe
From: Jeff Xu
This is V6 version, addressing comments from V5, without code logic
change.
History:
---
V6:
- mseal.rst: fix a typo (Randy Dunlap)
- security/Kconfig: add rr into note (Liam R. Howlett)
- remove mseal_system_mappings() and use macro instead (Liam R. Howlett)
- mseal.rs
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and MSEAL_SYSTEM_MAPPINGS_VM_FLAG
macro for future patches.
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
the vdso.
Testing passes on UML.
Signed-off-by: Jeff Xu
Tested-by: Benjamin Berg
---
arch/um/Kconfig| 1 +
arch/x86/um/vdso/vma.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 16 ++--
2 files cha
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 22
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
---
.../testing/selftests/x86/test_mremap_vdso.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c
b/tools/testi
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and a header file (userprocess.h)
for future patches.
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a given
From: Jeff Xu
The commit message in the first patch contains the full description of
this series.
--
History:
V5
- Remove kernel cmd line (Lorenzo Stoakes)
- Add test info (Lorenzo Stoakes)
- Add threat model info (Lorenzo Stoakes)
- Fix x86 selftest: test_mremap_vdso
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Signed-off-by: Jeff Xu
---
kernel/events/uprobe
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 23
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
the vdso.
Testing passes on UML.
Signed-off-by: Jeff Xu
Tested-by: Benjamin Berg
---
arch/um/Kconfig| 1 +
arch/x86/um/vdso/vma.c | 7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 17 +++--
2 files ch
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
---
.../testing/selftests/x86/test_mremap_vdso.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c
b/tools/testi
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and a header file (userprocess.h)
for future patches.
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a given
From: Jeff Xu
The commit message in the first patch contains the full description of
this series.
--
History:
V5
- Remove kernel cmd line (Lorenzo Stoakes)
- Add test info (Lorenzo Stoakes)
- Add threat model info (Lorenzo Stoakes)
- Fix x86 selftest: test_mremap_vdso
From: Jeff Xu
This change creates the initial version of memorysealing.c.
The introduction of memorysealing.c, which replaces mseal_test.c and
uses the kselftest_harness, aims to initiate a discussion on using the
selftest harness for memory sealing tests. Upon approval of this
approach, the mig
From: Jeff Xu
This change creates the initial version of memorysealing.c.
The introduction of memorysealing.c, which replaces mseal_test.c and
uses the kselftest_harness, aims to initiate a discussion on using the
selftest harness for memory sealing tests. Upon approval of this
approach, the mig
From: Jeff Xu
No code logic change.
can_do_mseal() is called exclusively by mseal.c, and mseal.c is compiled
only when CONFIG_64BIT flag is set in makefile. Therefore, it is
unnecessary to have 32 bit stub function in the header file, remove
this function and merge the logic into do_mseal().
L
From: Jeff Xu
History:
V2: remove the can_do_mseal (Liam.Howlett, Lorenzo Stoakes)
V1: initial version.
Jeff Xu (1):
mseal: move can_do_mseal() to mseal.c
mm/internal.h | 16
mm/mseal.c| 6 +++---
2 files changed, 3 insertions(+), 19 deletions(-)
--
2.47.0.338.g60cca
From: Jeff Xu
Hi Andrew,
Is that possible to squash this change on top of
"mseal: move can_do_mseal to mseal.c" on the mm-unstable ?
This is the first time I m doing this, because I saw dev did this before,
and saying this is the prefered approach.
I could also send v2 which is what I usually
From: Jeff Xu
No code logic change.
can_do_mseal is called exclusively by mseal.c,
and mseal.c is compiled only when CONFIG_64BIT flag is
set in makefile. Therefore, it is unnecessary to have
32 bit stub function in the header file.
Signed-off-by: Jeff Xu
---
mm/internal.h | 16 --
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing or unmapped during the life time of the process.
For complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing or unmapped during the life time of the process.
For complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing or unmapped during the life time of the process.
For complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing or unmapped during the life time of the process.
For complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such
From: Jeff Xu
It appears there is a regression on the latest mm,
when munmap sealed memory, it can cause unexpected VMA split.
E.g. repro use this test.
---
tools/testing/selftests/mm/mseal_test.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/tools/testing/selfte
From: Jeff Xu
Testcase for "Two fixes for madvise(MADV_DONTNEED) when sealed"
test_seal_madvise_prot_none
shall not block when mapping is PROT_NONE
test_madvise_filebacked_writable
shall not block writeable private filebacked mapping.
test_madvise_filebacked_was_writable - shall block.
s
From: Jeff Xu
Two fixes for madvise(MADV_DONTNEED) when sealed.
For PROT_NONE mappings, the previous blocking of
madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
order to free the page.
For file-backed, p
From: Jeff Xu
Two fixes for madvise(MADV_DONTNEED) when sealed.
For PROT_NONE mappings, the previous blocking of
madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
order to free the page.
For file-backed, p
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing during the life time of the process. For
complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such as vdso, vva
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing during the life time of the process. For
complete descriptions of memory sealing, please see mseal.rst [1].
System mappings such as vdso, vva
From: Jeff Xu
Change "overwrite" to overwrites"
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/mseal.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/mseal.rst
b/Documentation/userspace-api/mseal.rst
index 41102f74c5e2..54bbcce330ec 1
From: Jeff Xu
Update doc after in-loop change: mprotect/madvise can have
partially updated and munmap is atomic.
Fix indentation and clarify some sections to improve readability.
Signed-off-by: Jeff Xu
Fixes: df2a7df9a9aa ("mm/munmap: replace can_modify_mm with can_modify_vma")
Fixes: 4a2dd02b
From: Jeff Xu
Pedro Falcato's optimization [1] for checking sealed VMAs, which replaces
the can_modify_mm() function with an in-loop check, necessitates an update
to the mseal.rst documentation to reflect this change.
Furthermore, the document has received offline comments regarding the code
sam
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing during the life time of the process.
System mappings such as vdso, vvar, and sigpage (for arm) are
generated by the kernel during program ini
From: Jeff Xu
Seal vdso, vvar, sigpage, uprobes and vsyscall.
Those mappings are readonly or executable only, sealing can protect
them from ever changing during the life time of the process.
System mappings such as vdso, vvar, and sigpage (for arm) are
generated by the kernel during program ini
From: Jeff Xu
Update doc after in-loop change: mprotect/madvise can have
partially updated and munmap is atomic.
Fix indentation and clarify some sections to improve readability.
Signed-off-by: Jeff Xu
Fixes: df2a7df9a9aa ("mm/munmap: replace can_modify_mm with can_modify_vma")
Fixes: 4a2dd02b
From: Jeff Xu
Pedro Falcato's optimization [1] for checking sealed VMAs, which replaces
the can_modify_mm() function with an in-loop check, necessitates an update
to the mseal.rst documentation to reflect this change.
Furthermore, the document has received offline comments regarding the code
sam
From: Jeff Xu
Update doc after in-loop change: mprotect/madvise can have
partially updated and munmap is atomic.
Fix indentation and clarify some sections to improve readability.
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/mseal.rst | 290 --
1 file changed,
From: Jeff Xu
Pedro Falcato's optimization [1] for checking sealed VMAs, which replaces
the can_modify_mm() function with an in-loop check, necessitates an update
to the mseal.rst documentation to reflect this change.
Furthermore, the document has received offline comments regarding the code
sam
From: Jeff Xu
Some legacy SVr4 apps might depend on page on address zero
to be readable, however I can't find a reason that the page
ever becomes writeable, so seal it.
If there is a compain, we can make this configurable.
Signed-off-by: Jeff Xu
---
fs/binfmt_elf.c| 5 +
include/linu
From: Jeff Xu
In load_elf_binary as part of the execve(), when the current
task’s personality has MMAP_PAGE_ZERO set, the kernel allocates
one page at address 0. According to the comment:
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
and some applications "depend" upon this b
68 matches
Mail list logo