On Fri, Jan 24, 2020 at 4:46 PM [off-list ref] wrote:

quoted

Some systems can end up carrying lots of entries in the ima
measurement list. Since every entry is using a bit of kernel
memory, allow the sysadmin to export the measurement list to
the filesystem to free up some memory.

Signed-off-by: Janne Karhunen <redacted>

I like this approach, as it will work easily for measurement lists in
any format, and it will work for user or kernel triggering.

Yes, that was the point..

I'm getting an OOPS, though, whenever I write a filename to the
securityfs file (e.g. echo /var/log/ima.log > list_name).
Here's the relevant from syslog:

  BUG: unable to handle page fault for address: 00005650a0e7fe30
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0001) - permissions violation

  Oops: 0001 [#1] SMP NOPTI

  RIP: 0010:ima_write_list_name+0x35/0x114

I haven't had time to debug this. Any suggestions?

Interesting. I'm not a X86 man, but it looks like a SMAP trap to me.
In other words, the kernel was not allowed to read that
"/var/log/ima.log" string as SMAP protection was active for that piece
of memory. I was under the impression that the SMAP is disabled while
the copy_from_user is running..

I'll try on the X86 hardware and see if I can reproduce, maybe its off
by one read or something. Only X86 target I tested was QEMU.

quoted

+#define secfs_mnt    "/sys/kernel/security"
+#define am_filename  "/integrity/ima/ascii_runtime_measurements"

You probably really want to export the binary data, as that's
what's needed for attestation. (Or both, but that's trickier.)

That's why the file name was left as an argument to the export
function; you can export either one. I suppose we'd need some setting
to tell it which one to export.


--
Janne