On 01/11/2017 11:13 AM, Dave Hansen wrote:
On 01/11/2017 08:56 AM, Khalid Aziz wrote:
On 01/11/2017 09:33 AM, Dave Hansen wrote:
On 01/11/2017 08:12 AM, Khalid Aziz wrote:
A userspace task enables ADI through mprotect(). This patch series adds
a page protection bit PROT_ADI and a corresponding VMA flag
VM_SPARC_ADI. VM_SPARC_ADI is used to trigger setting TTE.mcd bit in the
sparc pte that enables ADI checking on the corresponding page.
Is there a cost in the hardware associated with doing this "ADI
checking"? For instance, instead of having this new mprotect()
interface, why not just always set TTE.mcd on all PTEs?
There is no performance penalty in the MMU to check tags, but if
PSTATE.mcd bit is set and TTE.mcde is set, the tag in VA must match what
was set on the physical page for all memory accesses.
OK, then I'm misunderstanding the architecture again.
For memory shared by two different processes, do they have to agree on
what the tags are, or can they differ?
The two processes have to agree on the tag. This is part of the security
design to prevent other processes from accessing pages belonging to
another process unless they know the tag set on those pages.
Potential for side
effects is too high in such case and would require kernel to either
track tags for every page as they are re-allocated or migrated, or scrub
pages constantly to ensure we do not get spurious tag mismatches. Unless
there is a very strong reason to blindly set TTE.mcd on every PTE, I
think the risk of instability is too high without lot of extra code.
Ahh, ok. That makes sense. Clearing the tags is expensive. We must
either clear tags or know the previous tags of the memory before we
access it.
Are any of the tags special? Do any of them mean "don't do any
checking", or similar?
Tag values of 0 and 15 can be considered special. Setting tag to 15 on
memory range is disallowed. Accessing a memory location whose tag is
cleared (means set to 0) with any tag value in the VA is allowed. Once a
tag is set on a memory, and PSTATE.mcde and TTE.mcd are set, there isn't
a tag that can be used to bypass version check by MMU.
Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
