Thread (29 messages) flat view 29 messages, 5 authors, 2018-02-22

[RFC PATCH v16 0/6] mm: security: ro protection for dynamic data

From: willy@infradead.org (Matthew Wilcox)
Date: 2018-02-20 23:56:00
Also in: linux-mm, lkml

On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
FWIW, I'm not wanting to use it to replace static variables. All the
structures are dynamically allocated right now, and get assigned to
other dynamically allocated pointers. I'd likely split the current
structures into a "ro after init" structure and rw structure, so
how does the "__ro_after_init" attribute work in that case? Is it
something like this?

struct xfs_mount {
	struct xfs_mount_ro{
		.......
	} *ro __ro_after_init;
	......
No, you'd do:

struct xfs_mount_ro {
	[...]
};

struct xfs_mount {
	const struct xfs_mount_ro *ro;
	[...]
};

We can't do protection on less than a page boundary, so you can't embed
a ro struct inside a rw struct.
Also, what compile time checks are in place to catch writes to
ro structure members? Is sparse going to be able to check this sort
of thing, like is does with endian-specific variables?
Just labelling the pointer const should be enough for the compiler to
catch unintended writes.
quoted
I'd be interested to have your review of the pmalloc API, if you think
something is missing, once I send out the next revision.
I'll look at it in more depth when it comes past again. :P
I think the key question is whether you want a slab-style interface
or whether you want a kmalloc-style interface.  I'd been assuming
the former, but Igor has implemented the latter already.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help