----- On Oct 13, 2017, at 9:57 AM, One Thousand Gnomes gnomes@xxxxxxxxxxxxxxxxxxx wrote: >> A maximum limit of 16 operations per cpu_opv syscall invocation is >> enforced, so user-space cannot generate a too long preempt-off critical >> section. > > Except that all the operations could be going to mmapped I/O space and if > I pick the right targets could take quite a long time to complete. We could check whether a struct page belongs to mmapped I/O space, and return EINVAL in that case. > It's > still only 16 operations - But 160ms is a lot worse than 10ms. In fact > with compare_iter I could make it much much worse still as I get 2 x > TMP_BUFLEN x 16 x worst case latency in my attack. That's enough to screw > up plenty of things. Would a check that ensures the page is not mmapped I/O space be sufficient to take care of this ? If happen to know which API I need to look for, it would be welcome. > > So it seems to me at minimum it needs to be restricted to genuine RAM user > pages, and in fact would be far far simpler code as well if it were > limited to a single page for a given invocation or if like futexes you > had to specifically create a per_cpu_opv mapping. I've had requests to implement per-cpu ring buffers with memcpy + offset pointer update restartable sequences. Having a memcpy operation which does not require page-alignment allows cpu_opv() to be used as a single-stepping fallback for those use-cases. I'm open to consider simplifying the other operations such as compare, add, bitwise ops, and shift ops by requiring that they target aligned content, which would therefore fit within a single page. However, given that we already want to support the unaligned memcpy operation, it does not add much extra complexity to support unaligned accesses for the other cases. We could also limit the "compare" operation to 1, 2, 4, 8 aligned bytes rather than being an up-to-PAGE_SIZE compare, but it would limit its usefulness in case of structure content comparison. Thanks, Mathieu > > Alan -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
