"H.J. Lu" hjl.tools@gmail.com writes:

Where should such a CET violation happen? I added a CET violation test to glibc:

void (*funcp) (void); funcp = mmap (NULL, 0x1000, PROT_EXEC | PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1); printf ("mmap = %p\n", funcp); /* Write RET instruction. */ *(char *) funcp = 0xc3; funcp ();

I can do something similar. But it is independent of nettle.

The reason it makes sense to have such a test in nettle is that nettle includes code (your patch) that affects if cet works. If practical, I'd prefer to do it with inline assembly rather than constructing code at run time, to not have to worry about flushing caches.

I suspect the tricky part is for the test to find out if cet protections are expected to work on the test system. Maybe one approch could be to have two test executables with a cet violation, one linking only to libc, and one linking also to nettle, hogweed and gmp. Then we'd expect that either both crash or none crash.

The regular tests have covered the nettle library with

$ ./configure CC='gcc -fcf-protextion=full' && make && make check

I got many CET violations on CET platform before my fix was merged.

That's excellent. What I worry is, now that it's is working fine, if some later change accidentally breaks cet marks. If that's not detected by tests, then applications linking with nettle will not get the cet protection at runtime, despite being compiled with -fcf-protection=full.

So it would be nice with an integration level test to catch that type of potential regression.

It's a bit special to test security features; it's not enough to test that everything works fine in the absense of attack, we need tests to model the attacks, at least when that's practical.

Regards, /Niels