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

[Li Wang]

Hi Liam,

On Thu, Mar 25, 2021 at 9:16 PM Liam Howlett <liam.howlett@oracle.com>
wrote:

> * Li Wang <liwang@redhat.com> [210325 04:37]:
> > 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.
>
> Just removing the PROT_EXEC invalidates the test.  However, if both
> PROT_EXEC and PROT_WRITE are removed, then the test still does what is
> intended.


> >
> >
> > >
> > > 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
>
>
> This was my test platform.  I also sent it to the Travis CI which passed
> for x86_64.  I will re-examine the accepted code to ensure the cosmetic
> changes didn't invalidate my testing.
>

FWIK, the Travis CI does not run test case, it just compiles/builds LTP
across
many arches/platforms.



>
>
> >
> > 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
> >
>
> Would you be willing to re-run the tests without both PROT_EXEC and
> PROT_WRITE?
>

Yes, it will always PASS without 'PROT_EXEC|PROT_WRITE'.

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