[LTP] [PATCH v2 1/1] brk02: Add test for removing more than one VMA

Li Wang liwang@redhat.com
Thu Mar 25 09:37:01 CET 2021


Hi Liam,

On Wed, Mar 24, 2021 at 12:27 AM Liam Howlett <liam.howlett@oracle.com>
wrote:

> Hello Li,
>
> Thank you for looking at this testcase.
>
> * Li Wang <liwang@redhat.com> [210317 07:08]:
> > Hi Liam, Petr,
> >
> > Liam Howlett <liam.howlett@oracle.com> wrote:
> >
> >
> > > ...
> > > +       if (mprotect(addr - page_size, page_size,
> > > +                    PROT_READ|PROT_WRITE|PROT_EXEC)) {
> > > +               tst_res(TFAIL, "Cannot mprotect new VMA.");
> > > +               return;
> > > +       }
> > >
> >
> > We got permission denied here while performing the brk02 on
> > x86_64/s390x(kernel-4.18~). After looking at the manual page of
> > mprotect(), seems the access issue caused by PROT_EXEC.
> >
> > "
> > POSIX says that the behavior of mprotect() is unspecified if it is
> applied
> > to a region of memory that was not obtained via mmap(2).
> > ...
> > Whether  PROT_EXEC has any effect different from PROT_READ
> > depends on processor architecture, kernel version, and process state.
> > If READ_IMPLIES_EXEC is set in the process's personality flags
> > (see personality(2)), specifying PROT_READ will implicitly add PROT_EXEC.
> > "
>
>
> Unforntunately, dropping the PROT_EXEC causes the VMA behaviour to
> change and does not test what this testcase is intended to test.
>

Yes, I agree with this. But am not sure if Linux take some action on
security
side to prevent setting PROT_EXEC permission arbitrary.


>
> Removing the PROT_EXEC and the PROT_WRITE does test what is supposed to
> be tested.  Can you verify that this works on the s390x?
>

Actually just removing the PROT_EXEC then the brk02 can be passed on all my
platforms.


>
> Are you using real hardware to test this or can I use some sort of
> emulation to test on my side?
>

It looks like easily to reproduce.

I get failed with both virtual system and bare metal, e.g. the first one
is on my Fedora33-workstation. But the worth to say, brk02 passed
with raspberry pi3 and pi4.

x86_64
-------------
# virt-what
# echo $?
0
# uname -r
5.10.22-200.fc33.x86_64
# ./brk02
tst_test.c:1289: TINFO: Timeout per run is 0h 05m 00s
brk02.c:41: TFAIL: Cannot mprotect new VMA

x86_64
-------------
# virt-what
kvm
# ./brk02
tst_test.c:1291: TINFO: Timeout per run is 0h 05m 00s
brk02.c:41: TFAIL: Cannot mprotect new VMA

s390x
-------------
# uname -r
5.12.0-rc4.vdso+
# virt-what
ibm_systemz
ibm_systemz-zvm
# ./brk02
tst_test.c:1289: TINFO: Timeout per run is 0h 05m 00s
brk02.c:41: TFAIL: Cannot mprotect new VMA


armv7l -- raspberry-pi3
-----------------------------
# uname  -r
5.4.96-v7.1.el7
# ./brk02
tst_test.c:1291: TINFO: Timeout per run is 0h 05m 00s
brk02.c:56: TPASS: munmap at least two VMAs of brk() passed
armv7l -- raspberry-pi4
-----------------------------
# uname  -rm
5.10.17-v7l+ armv7l
# ./brk02
tst_test.c:1291: TINFO: Timeout per run is 0h 05m 00s
brk02.c:56: TPASS: munmap at least two VMAs of brk() passed

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210325/5fe42f80/attachment.htm>


More information about the ltp mailing list