Kernel patch "ima: limit the number of ToMToU integrity violations"
prevents superfluous ToMToU violations. Add corresponding LTP tests.
Link:
https://lore.kernel.org/linux-integrity/20250228205505.476845-3-zo...@linux.ibm.com/
Signed-off-by: Mimi Zohar
---
.../integrity/ima/tests/ima_violatio
Violation tests are dependent on searching the $LOG file, which may
itself result in a ToMToU violation. Preempt getting an additional
violation during the tests by forcing the $LOG ToMToU violation
earlier.
Signed-off-by: Mimi Zohar
---
testcases/kernel/security/integrity/ima/tests/ima_violati
Kernel patch "ima: limit the number of open-writers integrity
violations" prevents superfluous "open-writers" violations. Add
corresponding LTP tests.
Link:
https://lore.kernel.org/linux-integrity/20250228205505.476845-2-zo...@linux.ibm.com/
Signed-off-by: Mimi Zohar
---
.../integrity/ima/test
On Sat, Mar 01, 2025 at 03:48:35AM +0200, Jarkko Sakkinen wrote:
On Fri, Feb 28, 2025 at 06:07:18PM +0100, Stefano Garzarella wrote:
This is primarily designed to support an enlightened driver for the
The commit message is half-way cut.
I.e. it lacks the explanation of "this".
AMD SVSM base
On Tue, 2025-03-04 at 13:57 +0100, Petr Vorel wrote:
> Hi Mimi,
>
> > Violation tests are dependent on searching the $LOG file, which may
> > itself result in a ToMToU violation. Preempt getting an additional
> > violation during the tests by forcing the $LOG ToMToU violation
> > earlier.
>
> >
On Tue, 2025-03-04 at 09:44 -0500, Mimi Zohar wrote:
> On Tue, 2025-03-04 at 14:31 +0100, Petr Vorel wrote:
> > Hi Mimi,
> >
> > > Add support for the number of expected violations. Include the
> > > expected number of violations in the output.
> >
> > Unfortunately this works only on fixed kern
Hi Mimi,
...
> > > + exec 3< $LOG || tst_brk TBROK "failed to read log file"
> > > tst_res TINFO "using log $LOG"
> > If you don't mind, I would reverse the order to get info about which log is
> > used:
> > tst_res TINFO "using log $LOG"
> > exec 3< $LOG || tst_brk TBROK "failed to re
Hi Mimi,
> Violation tests are dependent on searching the $LOG file, which may
> itself result in a ToMToU violation. Preempt getting an additional
> violation during the tests by forcing the $LOG ToMToU violation
> earlier.
> Signed-off-by: Mimi Zohar
> ---
> testcases/kernel/security/integri
Hi Mimi,
> Add support for the number of expected violations. Include the
> expected number of violations in the output.
Unfortunately this works only on fixed kernel (e.g. the one with v1 of your
"ima: limit both open-writers and ToMToU violations" kernel patchset [1]
(I haven't built v2 [2], b
On Tue, 2025-03-04 at 14:31 +0100, Petr Vorel wrote:
> Hi Mimi,
>
> > Add support for the number of expected violations. Include the
> > expected number of violations in the output.
>
> Unfortunately this works only on fixed kernel (e.g. the one with v1 of your
> "ima: limit both open-writers an
> On Tue, 2025-03-04 at 09:44 -0500, Mimi Zohar wrote:
> > On Tue, 2025-03-04 at 14:31 +0100, Petr Vorel wrote:
> > > Hi Mimi,
> > > > Add support for the number of expected violations. Include the
> > > > expected number of violations in the output.
> > > Unfortunately this works only on fixed
On Mon, 2025-03-03 at 12:55 -0400, Jason Gunthorpe wrote:
> On Sun, Mar 02, 2025 at 09:33:59PM +0200, Jarkko Sakkinen wrote:
> > WARNING: line length of 102 exceeds 100 columns
> > #764: FILE: drivers/char/tpm/tpm_crb.c:821:
> > + FW_BUG "TPM2 ACPI table has wrong
> > s
On Tue, Mar 04, 2025 at 04:23:51PM +0100, Stefano Garzarella wrote:
> > This commit got me lost tbh.
>
> Now I understand why you got lost, my bad!
No need for apologies, just merely reporting what I do or do not
understand with brutal honesty ;-)
> I checked further and these structures seem to
On 3/4/25 16:19, Jarkko Sakkinen wrote:
> On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
>> On 3/4/25 16:06, Jarkko Sakkinen wrote:
>>> + /*
>>> +* This is a micro-architectural requirement. ECREATE would detect this
>>> +* too without mentionable overhead but this check gua
The total size calculated for EPC can overflow u64 given the added up page
for SECS. Further, the total size calculated for shmem can overflow even
when the EPC size stays within limits of u64, given that it adds the extra
space for 128 byte PCMD structures (one for each page).
Address this by pr
On Wed, Mar 05, 2025 at 02:06:02AM +0200, Jarkko Sakkinen wrote:
> The total size calculated for EPC can overflow u64 given the added up page
> for SECS. Further, the total size calculated for shmem can overflow even
> when the EPC size stays within limits of u64, given that it adds the extra
> sp
On 3/4/25 16:06, Jarkko Sakkinen wrote:
> + /*
> + * This is a micro-architectural requirement. ECREATE would detect this
> + * too without mentionable overhead but this check guarantees also that
> + * the space calculations for EPC and shmem allocations never overflow.
> +
On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
> On 3/4/25 16:06, Jarkko Sakkinen wrote:
> > + /*
> > +* This is a micro-architectural requirement. ECREATE would detect this
> > +* too without mentionable overhead but this check guarantees also that
> > +* the space calc
Hi all,
> Default value was suitable only for x86_64. This helps to use other
> archs on distros which set $BOOT_IMAGE.
FYI merged.
Kind regards,
Petr
Hi all,
> Test requires not only func=CRITICAL_DATA IMA policy content but also
> ima_policy=critical_data kernel cmdline. Without cmdline no measures are
> done.
FYI merged.
Kind regards,
Petr
> https://ima-doc.readthedocs.io/en/latest/ima-policy.html#ima-policy-critical-data
> https://git.ker
Add support for the number of expected violations. Include the
expected number of violations in the output.
Signed-off-by: Mimi Zohar
---
.../security/integrity/ima/tests/ima_violations.sh | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/testcases/kernel/securi
On Mon, 2025-03-03 at 17:21 +0100, Stefano Garzarella wrote:
> On Sat, Mar 01, 2025 at 03:45:10AM +0200, Jarkko Sakkinen wrote:
> > On Fri, Feb 28, 2025 at 06:07:17PM +0100, Stefano Garzarella wrote:
> > > + int (*send_recv)(struct tpm_chip *chip, u8 *buf, size_t
> > > buf_len,
> > > +
On Tue, 2025-03-04 at 18:43 +0100, Petr Vorel wrote:
> > On Tue, 2025-03-04 at 09:44 -0500, Mimi Zohar wrote:
> > > On Tue, 2025-03-04 at 14:31 +0100, Petr Vorel wrote:
> > > > Hi Mimi,
>
> > > > > Add support for the number of expected violations. Include the
> > > > > expected number of violati
On Tue, Mar 04, 2025 at 06:56:02PM +0200, Jarkko Sakkinen wrote:
> On Mon, 2025-03-03 at 17:21 +0100, Stefano Garzarella wrote:
> > On Sat, Mar 01, 2025 at 03:45:10AM +0200, Jarkko Sakkinen wrote:
> > > On Fri, Feb 28, 2025 at 06:07:17PM +0100, Stefano Garzarella wrote:
> > > > + int (*send_r
On Mon, Mar 03, 2025 at 05:46:16PM +0100, Stefano Garzarella wrote:
> On Sat, Mar 01, 2025 at 03:51:46AM +0200, Jarkko Sakkinen wrote:
> > On Fri, Feb 28, 2025 at 06:07:19PM +0100, Stefano Garzarella wrote:
> > > Add driver for the vTPM defined by the AMD SVSM spec [1].
> > >
> > > The specificati
On Tue, Mar 04, 2025 at 04:30:21PM -0800, Dave Hansen wrote:
> On 3/4/25 16:19, Jarkko Sakkinen wrote:
> > On Tue, Mar 04, 2025 at 04:18:03PM -0800, Dave Hansen wrote:
> >> On 3/4/25 16:06, Jarkko Sakkinen wrote:
> >>> + /*
> >>> + * This is a micro-architectural requirement. ECREATE would detect
26 matches
Mail list logo
