From: Linus Torvalds > Sent: 31 December 2022 00:42 > ... > And on 64-bit, we really only need to check the high bit. > > In fact, we don't even want to *check* it, because then we need to do > that disgusting array_index_mask_nospec thing to mask the bits for it, > so it would be even better to use purely arithmetic with no > conditionals anywhere. > > And that's exactly what we could do on x86-64: > > movq %rdx,%rax > shrq $63,%rax > orq %rax,%rdx > > would actually be noticeably better than what we do now for for > TASK_SIZE checking _and_ for the array index masking (for putuser.S, > we'd use %rbx instead of %rax in that sequence). ... > It would just turn all kernel addresses into all ones, which is then > guaranteed to fault. So no need for any conditional that never > triggers in real life anyway. Are byte loads guaranteed to fault? I suspect the 'all ones' address can be assigned to io. So get/put_user for a byte probably needs a 'js' test after the 'orq'. (I don't think you need to worry about a apeculative load from an uncached address.) ... > And once we don't test against TASK_SIZE, the need for UNTAG_ADDR just > goes away, so now LAM is better too. > > In other words, we could actually improve on our current code _and_ > simplify the LAM situation. Win-win. Presumably the fault handler already has the code to untag addresses. It has to be said that I don't really see why tagging addresses is a significant benefit unless the hardware checks than the PTE/TLB is also set with the correct tag. All it seems to me that it does it make more 'random addresses' valid. Clearly interpreters can set and check the high address bits, but they can also mask them after the checks (or use xor to flip the bits and let the cpu fault on errors). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
