[kernel-hardening] [RFC v2][PATCH 02/11] lkdtm: add test for rare_write() infrastructure
From: Ian Campbell <hidden>
Date: 2017-03-30 10:17:58
Also in:
lkml
On Wed, 2017-03-29 at 11:15 -0700, Kees Cook wrote:
quoted hunk ↗ jump to hunk
diff --git a/drivers/misc/lkdtm_perms.c b/drivers/misc/lkdtm_perms.c index c7635a79341f..8fbadfa4cc34 100644 --- a/drivers/misc/lkdtm_perms.c +++ b/drivers/misc/lkdtm_perms.c[...] +/* This is marked __wr_rare, so it should ultimately be .rodata. */ +static unsigned long wr_rare __wr_rare = 0xAA66AA66; [...] +void lkdtm_WRITE_RARE_WRITE(void) +{ + /* Explicitly cast away "const" for the test. */
wr_rare isn't actually declared const above though? I don't think
__wr_rare includes a const, apologies if I missed it.
OOI, if wr_rare _were_ const then can the compiler optimise the a pair
of reads spanning the rare_write? i.e. adding const to the declaration
above to get:
static const unsigned long wr_rare __wr_rare = 0xAA66AA66;
x = wr_read;
rare_write(x, 0xf000baaa);
y = wr_read;
Is it possible that x == y == 0xaa66aa66 because gcc realises the x and
y came from the same const location? Have I missed a clobber somewhere
(I can't actually find a definition of __arch_rare_write_memcpy in this
series so maybe it's there), or is such code expected to always cast
away the const first?
I suppose such constructs are rare in practice in the sorts of places
where rare_write is appropriate, but with aggressive inlining it could
occur as an unexpected trap for the unwary perhaps.
Ian.