On Fri, Jan 24, 2020 at 4:46 PM <david.safford@xxxxxxxxx> wrote: > > 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 <janne.karhunen@xxxxxxxxx> > > 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. > > +#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
