linux-hardening - Re: [PATCH v2 0/4] Increase mseal test coverage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABi2SkWxAVzbZ8A4YOTcOhOOZwj6j_7K2khMs1yFDht1_GuLvg@mail.gmail.com>
Date: Fri, 30 Aug 2024 08:38:36 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Pedro Falcato <pedro.falcato@...il.com>
Cc: akpm@...ux-foundation.org, linux-kselftest@...r.kernel.org, 
	linux-mm@...ck.org, linux-hardening@...r.kernel.org, 
	linux-kernel@...r.kernel.org, willy@...radead.org, lorenzo.stoakes@...cle.com, 
	broonie@...nel.org, vbabka@...e.cz, Liam.Howlett@...cle.com, 
	rientjes@...gle.com, keescook@...omium.org
Subject: Re: [PATCH v2 0/4] Increase mseal test coverage

Hi Pedro

On Fri, Aug 30, 2024 at 5:31 AM Pedro Falcato <pedro.falcato@...il.com> wrote:
>
> On Thu, Aug 29, 2024 at 09:43:48PM GMT, jeffxu@...omium.org wrote:
> > From: Jeff Xu <jeffxu@...omium.org>
> >
> > This series increase the test coverage of mseal_test by:
> >
> > Add check for vma_size, prot, and error code for existing tests.
> > Add more testcases for madvise, munmap, mmap and mremap to cover
> > sealing in different scenarios.
> >
> > The increase test coverage hopefully help to prevent future regression.
> > It doesn't change any existing mm api's semantics, i.e. it will pass on
> > linux main and 6.10 branch.
>
> I do want to be clear that we shouldn't confuse "test coverage" with being unequivocally good
> if it has the possibility to paint ourselves into an API corner where details that should be left
> unspecified are instead set in stone (e.g do we want to test how mprotect behaves if it finds an msealed
> vma midway? no, apart from the property that really matters in this case (that sealed vmas remain untouched)).
>
I do not disagree with this. Let's look through code and comment on
the case directly if there is such a case.

Thanks.
-Jeff

> >
> > Note: in order to pass this test in mm-unstable, mm-unstable must have
> > Liam's fix on mmap [1]
> >
> > [1] https://lore.kernel.org/linux-kselftest/vyllxuh5xbqmaoyl2mselebij5ox7cseekjcvl5gmzoxxwd2he@hxi4mpjanxzt/#t
> >
> > History:
> > V2:
> > - remove the mmap fix (Liam R. Howlett will fix it separately)
> > - Add cover letter (Lorenzo Stoakes)
> > - split the testcase for ease of review (Mark Brown)
> >
> > V1:
> > - https://lore.kernel.org/linux-kselftest/20240828225522.684774-1-jeffxu@chromium.org/
> >
> > Jeff Xu (4):
> >   selftests/mm: mseal_test, add vma size check
> >   selftests/mm: mseal_test add sealed madvise type
> >   selftests/mm: mseal_test add more tests for mmap
> >   selftests/mm: mseal_test add more tests for mremap
> >
>
> nit: Please follow a more standard commit naming scheme like
>         selftests/mm: <change description>
> or
>         selftests/mseal: <change description>
>
> --
> Pedro