When to hide kernel structures from userspace and when to not hide them?

Newer versions of our linux distributions had their includes revised: A lot of kernel structures that were previously exported to userspace now are not exported anymore. To take an example, definitions of page size (macro PAGE_SIZE), usually found on asm/page.h, that used to be available when one installed the kernel-headers (or equivalent) package.

I see the point of hiding internal kernel structures from most userspace programs, usually they shouldn’t mess with such structures. But if your userspace program is actually a test for a kernel feature? Tests that are designed to test the kernel should be able to access those structures, otherwise we won’t be accurate and portable on our tests.

Example: I am getting the cerberus testsuite to compile under ubuntu 9.04 and opensuse 11. They both don’t have asm/page.h anymore and some of the code of the cerberus test suite use the PAGE_SIZE macro. Doing a bit of research points out to the fact that I should be using the getpagesize() function from unistd.h. Should I really?

unistd.h code:

/* Return the number of bytes in a page.  This is the system's page size,
which is not necessarily the same as the hardware page size.  */
extern int getpagesize (void)  __THROW __attribute__ ((__const__));

An inspection on the testsuite code shows me that the authors really meant to use the hardware page sizes:

/* Takes aligned buffers. Finds an arbitrary location in memory of a
* user process (must be passed as an array of ints) and translates
* it to physical memory location. All this without kernel support
* (besides /proc/kcore). Optionally specify a character alignment in
* case the memory buffer is not byte-aligned. */
/* Now compute the offset (in chars) of the error from the page
boundary. */
fail_page_offset = ((int) (&nbuf[offset])) % PAGE_SIZE

So, how do we handle ‘special’ userspace programs that are intended to test kernel and hardware? Do we still enforce this restriction of not being able to access kernel structures or we do have an alternative solution? Comments are very very much appreciated, I would like to get some ideas before I start to fix those suites…


2 thoughts on “When to hide kernel structures from userspace and when to not hide them?

  1. Most likely, the kernel page size is actually what you care about, not the hardware page size. The only way they can differ is when the kernel uses 16 4kb hardware pages to make a logical 64kb page on hardware that doesn’t support native 64kb pages in hardware. In this case, assuming 64kb physical pages makes sense from the application point of view.

    On a separate note, the comment looks very suspicious. It’s trying to find out the physical address of a page without kernel support. If that is indeed possible, that could become part of a security hole that should be fixed. The kernel tries hard to prevent users from knowing about physical addresses so that in the presence of a DMA hole, it can’t send arbitrary data to/from a PCI device.

  2. I agree, usually the kernel page size is what we care about on this particular case.

    Interesting comment about the security hole. I need to re-read the source code and see if on that particular segment of the code the author manages to find the physical address of a page without kernel support.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s