| History log of /src/tests/lib/libc/arch |
| Revision | Date | Author | Comments |
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 27-Jul-2018 |
ryo | aarch64 support per page execute protection
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.24; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 1.1.26.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1.24.1 | 28-Jul-2018 |
pgoyette | Sync with HEAD
|
| 1.1.4.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.1.4.1 | 10-Aug-2014 |
tls | file exec_prot_support.c was added on branch tls-maxphys on 2014-08-20 00:04:49 +0000
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 1.1.4.2 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.1.4.1 | 10-Aug-2014 |
tls | file return_one.S was added on branch tls-maxphys on 2014-08-20 00:04:49 +0000
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 30-Dec-2017 |
martin | Implement helper function for alpha
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.34;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.34.1 | 26-Feb-2018 |
snj | Pull up following revision(s) (requested by maya in ticket #582):
tests/lib/libc/arch/alpha/return_one.S: 1.2
Implement helper function for alpha
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 26-Jan-2014 |
matt | Make this real even though it isn't yet used.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.2; 1.1.8;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.8.1 | 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.1.2.1 | 22-May-2014 |
yamt | sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.4 | 31-May-2022 |
skrll | Avoid plabels on hppa to make some tests not crash
|
| 1.3 | 31-May-2022 |
skrll | whitespace including space before delay slot instruction.
|
| 1.2 | 14-Feb-2019 |
mrg | implement return_one for hppa, mips, ppc64, and vax.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.42;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.42.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 05-Aug-2016 |
scole | PR port-ia64/51261
Fix for ia64
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.24;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.24.1 | 06-Aug-2016 |
pgoyette | Sync with HEAD
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 10-Feb-2019 |
mlelstv | provide a test function, avoids crashing tests with SIGSEGV.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.42;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.42.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.3 | 21-Jan-2021 |
simonb | Use .set noreorder and use reg names.
atf- lib/libc/sys/t_mprotect mprotect_mremap_exec is a bit happier now.
|
| 1.2 | 14-Feb-2019 |
mrg | implement return_one for hppa, mips, ppc64, and vax.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.42;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.42.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1 | 03-Sep-2014 |
matt | New files for OR1K support
|
| 1.1 | 03-Sep-2014 |
matt | New files for OR1K support
|
| 1.2 | 16-Mar-2012 |
matt | Allow testing of exec pages on PowerPC BookE.
Make return_one actually do the right thing.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.2; 1.1.4;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.4.1 | 17-May-2012 |
riz | Pull up following revision(s) (requested by matt in ticket #252):
tests/lib/libc/arch/powerpc/exec_prot_support.c: revision 1.2
tests/lib/libc/arch/powerpc/return_one.S: revision 1.2
Allow testing of exec pages on PowerPC BookE.
Make return_one actually do the right thing.
|
| 1.1.2.1 | 17-Apr-2012 |
yamt | sync with head
|
| 1.3 | 29-Mar-2015 |
matt | add return_one_start
|
| 1.2 | 16-Mar-2012 |
matt | Allow testing of exec pages on PowerPC BookE.
Make return_one actually do the right thing.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.2; 1.1.4;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.4.1 | 17-May-2012 |
riz | Pull up following revision(s) (requested by matt in ticket #252):
tests/lib/libc/arch/powerpc/exec_prot_support.c: revision 1.2
tests/lib/libc/arch/powerpc/return_one.S: revision 1.2
Allow testing of exec pages on PowerPC BookE.
Make return_one actually do the right thing.
|
| 1.1.2.1 | 17-Apr-2012 |
yamt | sync with head
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 14-Feb-2019 |
mrg | implement return_one for hppa, mips, ppc64, and vax.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.42;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.42.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1 | 19-Sep-2014 |
matt | New files for Userland support of UCB RISC-V (both 32-bit and 64-bit)
|
| 1.2 | 28-Mar-2015 |
matt | Update for new RISCV ABI
|
| 1.1 | 19-Sep-2014 |
matt | New files for Userland support of UCB RISC-V (both 32-bit and 64-bit)
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 20-Jul-2017 |
uwe | Don't execute random garbage. Fixes mprotect_mremap_exec test.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.34;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.34.1 | 25-Jul-2017 |
snj | Pull up following revision(s) (requested by uwe in ticket #148):
tests/lib/libc/arch/sh3/return_one.S: revision 1.2
Don't execute random garbage. Fixes mprotect_mremap_exec test.
|
| 1.2 | 14-Jan-2018 |
martin | Sync sparc with sparc64
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 14-Jan-2018 |
martin | Sync sparc with sparc64
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 31-Dec-2016 |
martin | All sparc64 CPUs support per page execute protection.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.24;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.24.1 | 07-Jan-2017 |
pgoyette | Sync with HEAD. (Note that most of these changes are simply $NetBSD$
tag issues.)
|
| 1.3 | 08-Feb-2021 |
joerg | Don't define a label twice.
|
| 1.2 | 31-Dec-2016 |
martin | All sparc64 CPUs support per page execute protection.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.24;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.24.1 | 07-Jan-2017 |
pgoyette | Sync with HEAD. (Note that most of these changes are simply $NetBSD$
tag issues.)
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.2 | 14-Feb-2019 |
mrg | implement return_one for hppa, mips, ppc64, and vax.
|
| 1.1 | 18-Jul-2011 |
jym | branches: 1.1.42;
Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1.42.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
| 1.1 | 18-Jul-2011 |
jym | Add a simple test case to check executable mapping rights for mprotect(2).
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
|
