Re: [patch 0/5] Support for sanitization flag in low-level page allocator

You do at buffer free time.

Alan, I think you will agree with me that forcing people to know what
they have to do exactly with their buffers when they will contain
confidential/sensitive data is suboptimal. Like it's been said before,

In the kernel no and page flags are very precious, very few and if we run
out will cost us a vast amount of extra kernel memory. If page flags were
free the question would be trivial - but they are not. Thus it is worth
asking whether its actually harder to remember to zap the buffer or set
and clear the flag correctly.

the clearing isn't the only issue here. We have pagination to disk,
re-allocation leaks, etc.

There is no kernel paging (except virtualised but that is an entire other
can of worms we shouldn't open), you can handle reallocation concerns
without page flags by using a SLAB type for 'secure' allocations which
clears the entry on free.

Still doesn't need a page flag - that is a vma flag which is far cheaper.
Also means you can get rid of the stupid mlock() misuse by things like
GPG to work around OS weaknesses by crypting the page if it hits
disk/swap/whatever.

Do you suggest a vma flag should be created for this as well?

You don't need a page flag, just a per vma flag and something akin to
madvise() to set the flag on the VMA (and/or split the VMA for partial
maps as we do for anything else). VMA flags are cheap.

The point is that the keys or sensitive marked pages should never, ever
be swapped to disk, by any means. Right now the patch only affects
kernel code, the task related flag and functionality patches haven't been
submitted yet.

If you are paging them to a crypted filestore they should be safe on
disk. What is your problem with that ? If your suspend image is
compromised it doesn't really matter if you wiped the data as what you
resume may then wait for the new keys and compromise those. In fact
having a page flag makes it easier for the attack code to know what to
capture and send to the bad guys...

Regarding retrieving the encryption keys, IVs, and so forth, why bother
reading the data remaining on disk? You can just retrieve them off
memory (ex. via rogue driver or some re-allocation bug scenario,
information leak or similar issue) and that's it.

I was assuming you'd wipe such data from memory on a suspend to disk.
However on a suspend to disk its basically as cheap to wipe all of memory
and safer than wiping random bits and praying you know what the compiler
did and you know what some other bit of library did.

After all, that was the beauty of Linux since the start. We don't need
to follow a political or corporate agenda in these regards. Right?

Indeed - but a technically sound solution that doesn't waste a page flag
is still important. It's btw not as simple as a page flag anyway - the
kernel stores some stuff in places that do not have page flags, it also
has kmaps and other things that will give you suprises.

Perhaps you should post your threat model to go with the patches. At the
moment your model doesn't seem to make sense.

Surely we can attack the problem far more directly for all but S2R by

- choosing to use encrypted swap and encrypted S2D images (already
possible)
- wiping the in memory image on S2D if the user chooses (which would be
smart)

That has the advantage that nobody has to label pages sensitive - which
is flawed anyway, we want to label pages "non-sensitive" in the ideal
world so we default secure.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [Vuln-Dev Challenge] - VulnDev1.c Summary
    ... means that 0x4, 0x5, and 0x8 all do not have the IS_MMAPPED flag set. ... /* size field is or'ed with PREV_INUSE when previous adjacent chunk in use ... > turn calls munmap on an invalid memory address. ... >> glance it may appear that exploitation could occur during free. ...
    (Vuln-Dev)
  • Re: Using memory mapped files to quickly transfer data between pro
    ... Does FILE_FLAG_NO_BUFFERING makes any difference for memory mapping? ... on the file and it displayed the data the first process had written to ... If you want to check whether disk IO is really happening you can ... This flag should only used with regualr file IO ...
    (microsoft.public.win32.programmer.kernel)
  • Re: V4FX PPC suspend/resume
    ... Austin's answers seems more robust assuming you clear the "warm boot" flag in step 5 of the resume process. ... copy all of memory to a non-volatile storage ... Copy the saved memory from the non-volatile storage device to ...
    (comp.arch.fpga)
  • Re: [RFC patch] introduce sys_membarrier(): process-wide memory barrier (v9)
    ... This synchronization only takes care of threads using the current process memory ... I am tempted to say that we should probably wait for users of this API feature ... So when userspace start using this flag on old kernels that do not ...
    (Linux-Kernel)
  • Re: [patch 0/9] Critical Mempools
    ... I'm more in favour of a proper reservation system. ... > could reserve memory for a critical process to use, ... >>Well, I've got patches that implement the GFP flag approach, but as I ... networking stack, to keep the network alive under periods of extreme VM ...
    (Linux-Kernel)