lkml.org 
[lkml]   [2017]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
From
Date
On 01/06/2017 02:19 AM, Michal Hocko wrote:
> On Thu 05-01-17 13:30:10, Khalid Aziz wrote:
> [...]
>> It is very tempting to restrict tags to PAGE_SIZE granularity since it makes
>> code noticeably simpler and that is indeed going to be the majority of
>> cases. Sooner or later somebody would want to use multiple tags per page
>> though.
>
> I didn't get to read the patch throughly yet but I am really confused by
> this statement. The api is mprotect based which makes it ineherently
> PAGE_SIZE granular. How do you want to achieve cache line granularity
> with this API?
>
> And I would really vote for simplicity first... Subpage granularity
> sounds way too tricky...
>

Hi Michal,

ADI can be enabled for subsets of a task's address space. It takes three
steps to enable ADI completely:

1. Enable the task to use ADI by setting PSTATE.mcde bit. This is the
master switch for ADI. mprotect() does this in my patch. Granularity for
this operation is entire address space for the task.

2. Set TTE.mcd bit for each page translation for the pages one wants ADI
enabled on. mprotect() does this as well in my patch. Granularity for
this operation is per page.

3. Set version tag for the addresses task wants to enable ADI on using
"stxa" instruction. This is done entirely in userspace with no
assistance or intervention needed from the kernel. Granularity for this
operation is cache line size which is 64 bytes on Sparc M7.

I agree with you on simplicity first. Subpage granularity is complex,
but the architecture allows for subpage granularity. Maybe the right
approach is to support this at page granularity first for swappable
pages and then expand to subpage granularity in a subsequent patch?
Pages locked in memory can already use subpage granularity with my patch.

Thanks,
Khalid

\
 
 \ /
  Last update: 2017-01-06 16:34    [W:0.095 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site