Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1351039 > unrolled thread

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-06 05:10 +0100
    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 16:10 +0100
      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-07 16:40 +0100
        Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 16:50 +0100
        Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 16:50 +0100
          Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 17:10 +0100
            Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 18:50 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 19:00 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 19:20 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:50 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 20:00 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:30 +0100
                        Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 20:50 +0100
                          Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2016-03-07 23:50 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 02:40 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:10 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-08 21:00 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 21:20 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-08 21:30 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 22:10 +0100
      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 17:50 +0100
        Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:00 +0100
      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 18:00 +0100
        Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 19:10 +0100
          Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:30 +0100
            Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 20:00 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:30 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 20:50 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 21:00 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 21:50 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:00 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Andy Lutomirski <luto@amacapital.net> - 2016-03-07 22:10 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:20 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 00:40 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 01:00 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) James Morris <james.l.morris@oracle.com> - 2016-03-08 10:40 +0100
        Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:10 +0100
          Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-07 19:20 +0100
            Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 19:30 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:20 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:40 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:40 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:20 +0100
                      Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-08 05:20 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:20 +0100
                    Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 00:30 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-08 01:30 +0100
                  Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-08 05:30 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Rob Gardner <rob.gardner@oracle.com> - 2016-03-08 00:40 +0100
          Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 20:10 +0100
            Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 22:30 +0100
              Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) David Miller <davem@davemloft.net> - 2016-03-07 22:40 +0100
                Re: [PATCH v2] sparc64: Add support for Application Data Integrity  (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2016-03-07 23:40 +0100

Page 1 of 3  [1] 2 3  Next page →

#1351039 — Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

From: Khalid Aziz <khalid.aziz@oracle.com>
Date: Wed,  2 Mar 2016 13:39:37 -0700

> 	In this
> 	first implementation I am enabling ADI for hugepages only
> 	since these pages are locked in memory and hence avoid the
> 	issue of saving and restoring tags.

This makes the feature almost entire useless.

Non-hugepages must be in the initial implementation.

> +	PR_ENABLE_SPARC_ADI - Enable ADI checking in all pages in the address
> +		range specified. The pages in the range must be already
> +		locked. This operation enables the TTE.mcd bit for the
> +		pages specified. arg2 is the starting address for address
> +		range and must be page aligned. arg3 is the length of
> +		memory address range and must be a multiple of page size.

I strongly dislike this interface, and it makes the prtctl cases look
extremely ugly and hide to the casual reader what the code is actually
doing.

This is an mprotect() operation, so add a new flag bit and implement
this via mprotect please.

Then since you are guarenteed to have a consistent ADI setting for
every single VMA region, you never "lose" the ADI state when you swap
out.  It's implicit in the VMA itself, because you'll store in the VMA
that this is an ADI region.

I also want this enabled unconditionally, without any Kconfig knobs.

Thanks.

[toc] | [next] | [standalone]

#1351684

On 03/05/2016 09:07 PM, David Miller wrote:
> From: Khalid Aziz <khalid.aziz@oracle.com>
> Date: Wed,  2 Mar 2016 13:39:37 -0700
>
>> 	In this
>> 	first implementation I am enabling ADI for hugepages only
>> 	since these pages are locked in memory and hence avoid the
>> 	issue of saving and restoring tags.
>
> This makes the feature almost entire useless.
>
> Non-hugepages must be in the initial implementation.

Hi David,

Thanks for the feedback. I will get this working for non-hugepages as 
well. ADI state of each VMA region is already stored in the VMA itself 
in my first implementation, so I do not lose it when the page is swapped 
out. The trouble is ADI version tags for each VMA region have to be 
stored on the swapped out pages since the ADI version tags are flushed 
when TLB entry for a page is flushed. When that page is brought back in, 
its version tags have to be set up again. Version tags are set on 
cacheline boundary and hence there can be multiple version tags for a 
single page. Version tags have to be stored in the swap space somehow 
along with the page. I can start out with allowing ADI to be enabled 
only on pages locked in memory.

>
>> +	PR_ENABLE_SPARC_ADI - Enable ADI checking in all pages in the address
>> +		range specified. The pages in the range must be already
>> +		locked. This operation enables the TTE.mcd bit for the
>> +		pages specified. arg2 is the starting address for address
>> +		range and must be page aligned. arg3 is the length of
>> +		memory address range and must be a multiple of page size.
>
> I strongly dislike this interface, and it makes the prtctl cases look
> extremely ugly and hide to the casual reader what the code is actually
> doing.
>
> This is an mprotect() operation, so add a new flag bit and implement
> this via mprotect please.

That is an interesting idea. Adding a PROT_ADI protection to mprotect() 
sounds cleaner. There are three steps to enabling ADI - (1) set 
PSTATE.mcde bit which is not tied to any VMA, (2) set TTE.mcd for each 
VMA, and (3) set the version tag on cacheline using MCD ASI. I can 
combine steps 1 and 2 in one mprotect() call. That will leave 
PR_GET_SPARC_ADICAPS and PR_GET_SPARC_ADI_STATUS prctl commands still to 
be implemented. PR_SET_SPARC_ADI is also used to check if the process 
has PSTATE.mcde bit set. I could use PR_GET_SPARC_ADI_STATUS to do that 
where return values of 0 and 1 mean the same as before and possibly add 
return value of 2 to mean PSTATE.mcde is not set?

>
> Then since you are guarenteed to have a consistent ADI setting for
> every single VMA region, you never "lose" the ADI state when you swap
> out.  It's implicit in the VMA itself, because you'll store in the VMA
> that this is an ADI region.
>
> I also want this enabled unconditionally, without any Kconfig knobs.
>

I can remove CONFIG_SPARC_ADI. It does mean this code will be built into 
32-bit kernels as well but it will be inactive code.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1351718

On 03/07/2016 07:07 AM, Khalid Aziz wrote:
> On 03/05/2016 09:07 PM, David Miller wrote:
>> From: Khalid Aziz <khalid.aziz@oracle.com>
>> Date: Wed,  2 Mar 2016 13:39:37 -0700
>>
>>>     In this
>>>     first implementation I am enabling ADI for hugepages only
>>>     since these pages are locked in memory and hence avoid the
>>>     issue of saving and restoring tags.
>>
>> This makes the feature almost entire useless.
>>
>> Non-hugepages must be in the initial implementation.
>
> Hi David,
>
> Thanks for the feedback. I will get this working for non-hugepages as 
> well. ADI state of each VMA region is already stored in the VMA itself 
> in my first implementation, so I do not lose it when the page is 
> swapped out. The trouble is ADI version tags for each VMA region have 
> to be stored on the swapped out pages since the ADI version tags are 
> flushed when TLB entry for a page is flushed. 


Khalid,

Are you sure about that last statement? My understanding is that the 
tags are stored in physical memory, and remain there until explicitly 
changed or removed, and so flushing a TLB entry has no effect on the ADI 
tags. If it worked the way you think, then somebody would have to 
potentially reload a long list of ADI tags on every TLB miss.

Rob



> When that page is brought back in, its version tags have to be set up 
> again. Version tags are set on cacheline boundary and hence there can 
> be multiple version tags for a single page. Version tags have to be 
> stored in the swap space somehow along with the page. I can start out 
> with allowing ADI to be enabled only on pages locked in memory.
>
>>
>>> +    PR_ENABLE_SPARC_ADI - Enable ADI checking in all pages in the 
>>> address
>>> +        range specified. The pages in the range must be already
>>> +        locked. This operation enables the TTE.mcd bit for the
>>> +        pages specified. arg2 is the starting address for address
>>> +        range and must be page aligned. arg3 is the length of
>>> +        memory address range and must be a multiple of page size.
>>
>> I strongly dislike this interface, and it makes the prtctl cases look
>> extremely ugly and hide to the casual reader what the code is actually
>> doing.
>>
>> This is an mprotect() operation, so add a new flag bit and implement
>> this via mprotect please.
>
> That is an interesting idea. Adding a PROT_ADI protection to 
> mprotect() sounds cleaner. There are three steps to enabling ADI - (1) 
> set PSTATE.mcde bit which is not tied to any VMA, (2) set TTE.mcd for 
> each VMA, and (3) set the version tag on cacheline using MCD ASI. I 
> can combine steps 1 and 2 in one mprotect() call. That will leave 
> PR_GET_SPARC_ADICAPS and PR_GET_SPARC_ADI_STATUS prctl commands still 
> to be implemented. PR_SET_SPARC_ADI is also used to check if the 
> process has PSTATE.mcde bit set. I could use PR_GET_SPARC_ADI_STATUS 
> to do that where return values of 0 and 1 mean the same as before and 
> possibly add return value of 2 to mean PSTATE.mcde is not set?
>
>>
>> Then since you are guarenteed to have a consistent ADI setting for
>> every single VMA region, you never "lose" the ADI state when you swap
>> out.  It's implicit in the VMA itself, because you'll store in the VMA
>> that this is an ADI region.
>>
>> I also want this enabled unconditionally, without any Kconfig knobs.
>>
>
> I can remove CONFIG_SPARC_ADI. It does mean this code will be built 
> into 32-bit kernels as well but it will be inactive code.
>
> Thanks,
> Khalid
>
>
>

[toc] | [prev] | [next] | [standalone]

#1351727

On 03/07/2016 08:30 AM, Rob Gardner wrote:
> On 03/07/2016 07:07 AM, Khalid Aziz wrote:
>> On 03/05/2016 09:07 PM, David Miller wrote:
>>> From: Khalid Aziz <khalid.aziz@oracle.com>
>>> Date: Wed,  2 Mar 2016 13:39:37 -0700
>>>
>>>>     In this
>>>>     first implementation I am enabling ADI for hugepages only
>>>>     since these pages are locked in memory and hence avoid the
>>>>     issue of saving and restoring tags.
>>>
>>> This makes the feature almost entire useless.
>>>
>>> Non-hugepages must be in the initial implementation.
>>
>> Hi David,
>>
>> Thanks for the feedback. I will get this working for non-hugepages as
>> well. ADI state of each VMA region is already stored in the VMA itself
>> in my first implementation, so I do not lose it when the page is
>> swapped out. The trouble is ADI version tags for each VMA region have
>> to be stored on the swapped out pages since the ADI version tags are
>> flushed when TLB entry for a page is flushed.
>
>
> Khalid,
>
> Are you sure about that last statement? My understanding is that the
> tags are stored in physical memory, and remain there until explicitly
> changed or removed, and so flushing a TLB entry has no effect on the ADI
> tags. If it worked the way you think, then somebody would have to
> potentially reload a long list of ADI tags on every TLB miss.
>
> Rob
>

Hi Rob,

I am fairly sure that is the case. This is what I found from the 
processor guys and others working on ADI. I tested it out by setting up 
ADI on normal malloc'd pages that got swapped out and I got MCD 
exceptions when those pages were swapped back in on access.

I mis-spoke when I said "....ADI version tags are flushed when TLB entry 
for a page is flushed". I meant ADI version tags are flushed when 
mapping for a virtual address is removed from TSB, not when TLB entry is 
flushed. Yes, ADI tags are stored in physical memory and removed when 
mapping is removed.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1351737 — Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

On Mon, Mar 7, 2016 at 7:30 AM, Rob Gardner <rob.gardner@oracle.com> wrote:
> On 03/07/2016 07:07 AM, Khalid Aziz wrote:
>>
>> On 03/05/2016 09:07 PM, David Miller wrote:
>>>
>>> From: Khalid Aziz <khalid.aziz@oracle.com>
>>> Date: Wed,  2 Mar 2016 13:39:37 -0700
>>>
>>>>     In this
>>>>     first implementation I am enabling ADI for hugepages only
>>>>     since these pages are locked in memory and hence avoid the
>>>>     issue of saving and restoring tags.
>>>
>>>
>>> This makes the feature almost entire useless.
>>>
>>> Non-hugepages must be in the initial implementation.
>>
>>
>> Hi David,
>>
>> Thanks for the feedback. I will get this working for non-hugepages as
>> well. ADI state of each VMA region is already stored in the VMA itself in my
>> first implementation, so I do not lose it when the page is swapped out. The
>> trouble is ADI version tags for each VMA region have to be stored on the
>> swapped out pages since the ADI version tags are flushed when TLB entry for
>> a page is flushed.
>
>
>
> Khalid,
>
> Are you sure about that last statement? My understanding is that the tags
> are stored in physical memory, and remain there until explicitly changed or
> removed, and so flushing a TLB entry has no effect on the ADI tags. If it
> worked the way you think, then somebody would have to potentially reload a
> long list of ADI tags on every TLB miss.
>

I'll bite, since this was sent to linux-api:

Can someone explain what this feature does for the benefit of people
who haven't read the manual (and who don't even know where to find the
manual)?

Are the top few bits of a sparc64 virtual address currently
must-be-zero?  Does this feature change the semantics so that those
bits are ignored for address resolution and instead must match
whatever the ADI tag is determined to be during address resolution?

Is this enforced for both user and kernel accesses?

Is the actual ADI tag associated with a "page" associated with the
page of physical memory or is it associated with a mapping?  That is,
if there are two virtual aliases of the same physical page (in the
same process or otherwise), does the hardware require them to have the
same ADI tag?  If the answer is no, then IMO this is definitely
something that should use mprotect and you should seriously consider
using something like mprotect_key (new syscall, not in Linus' tree
yet) for it.  In fact, you might consider a possible extra parameter
to that syscall for this purpose.

Cc: Dave Hansen.  It seems to be the zeitgeist to throw tag bits at
PTEs these days.

[toc] | [prev] | [next] | [standalone]

#1351744

On 03/07/2016 08:43 AM, Andy Lutomirski wrote:
> On Mon, Mar 7, 2016 at 7:30 AM, Rob Gardner <rob.gardner@oracle.com> wrote:
>> On 03/07/2016 07:07 AM, Khalid Aziz wrote:
>>>
>>> On 03/05/2016 09:07 PM, David Miller wrote:
>>>>
>>>> From: Khalid Aziz <khalid.aziz@oracle.com>
>>>> Date: Wed,  2 Mar 2016 13:39:37 -0700
>>>>
>>>>>      In this
>>>>>      first implementation I am enabling ADI for hugepages only
>>>>>      since these pages are locked in memory and hence avoid the
>>>>>      issue of saving and restoring tags.
>>>>
>>>>
>>>> This makes the feature almost entire useless.
>>>>
>>>> Non-hugepages must be in the initial implementation.
>>>
>>>
>>> Hi David,
>>>
>>> Thanks for the feedback. I will get this working for non-hugepages as
>>> well. ADI state of each VMA region is already stored in the VMA itself in my
>>> first implementation, so I do not lose it when the page is swapped out. The
>>> trouble is ADI version tags for each VMA region have to be stored on the
>>> swapped out pages since the ADI version tags are flushed when TLB entry for
>>> a page is flushed.
>>
>>
>>
>> Khalid,
>>
>> Are you sure about that last statement? My understanding is that the tags
>> are stored in physical memory, and remain there until explicitly changed or
>> removed, and so flushing a TLB entry has no effect on the ADI tags. If it
>> worked the way you think, then somebody would have to potentially reload a
>> long list of ADI tags on every TLB miss.
>>
>
> I'll bite, since this was sent to linux-api:
>
> Can someone explain what this feature does for the benefit of people
> who haven't read the manual (and who don't even know where to find the
> manual)?
>
> Are the top few bits of a sparc64 virtual address currently
> must-be-zero?  Does this feature change the semantics so that those
> bits are ignored for address resolution and instead must match
> whatever the ADI tag is determined to be during address resolution?
>
> Is this enforced for both user and kernel accesses?
>
> Is the actual ADI tag associated with a "page" associated with the
> page of physical memory or is it associated with a mapping?  That is,
> if there are two virtual aliases of the same physical page (in the
> same process or otherwise), does the hardware require them to have the
> same ADI tag?  If the answer is no, then IMO this is definitely
> something that should use mprotect and you should seriously consider
> using something like mprotect_key (new syscall, not in Linus' tree
> yet) for it.  In fact, you might consider a possible extra parameter
> to that syscall for this purpose.
>
> Cc: Dave Hansen.  It seems to be the zeitgeist to throw tag bits at
> PTEs these days.
>

Hi Andy,

The primary purpose of this feature is to prevent rogue accesses to 
memory regions. If a database were to allocate memory pages to cache 
database, it can enable ADI on those pages and set version tags. Version 
tag for a memory address is encoded in bits 63-60 in the virtual 
address. When accessing an ADI enabled memory region, top 4 bits of the 
virtual address presented to the MMU must match the version tag set 
earlier. When these bits do not match a tag, an MCD (Memory Corruption 
Detected) exception is raised. Kernel sends a SIGBUS to the offending 
process in response. There is some more info on ADI at 
<https://swisdev.oracle.com/_files/What-Is-ADI.html>.

Top 4-bits of sparc64 virtual address are used for version tag only when 
a process has its PSTATE.mcde bit set and it is accessing a memory 
region that has ADI enabled on it (TTE.mcd set) and a version tag was 
set on the virtual address being accessed. These 4-bits retain their 
original semantics in all other cases.

ADI version tags are checked for data fetches only. My implementation 
enforces this for userspace addresses only. Expanding this to include 
kernel data addresses as well will be a good thing to do to protect 
kernel data but I want to try to do this incrementally - (1) ADI for 
userspace addresses only for mlock'd pages, (2) expand support to 
swappable pages, (3) ADI for kernel data pages, (4)......whatever else 
makes sense...

ADI version tag applies to virtual addresses only. If two processes have 
virtual addresses mapping to the same physical page, they must use the 
same tag. Hardware will send MCD exception if the tags do not match. 
This was done to ensure a hack does not bypass ADI protection by simply 
inserting another VA-to-PA mapping. I do like the idea of mprotect() as 
David suggested and it can be done with existing mprotect() call. I will 
have to add a new key PROT_ADI to support this.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1351833

On 03/07/2016 08:06 AM, Khalid Aziz wrote:
> Top 4-bits of sparc64 virtual address are used for version tag only when
> a process has its PSTATE.mcde bit set and it is accessing a memory
> region that has ADI enabled on it (TTE.mcd set) and a version tag was
> set on the virtual address being accessed. These 4-bits retain their
> original semantics in all other cases.

OK, so this effectively reduces the address space of a process using the
feature.  Do we need to do anything explicit to keep an app from using
that address space?  Do we make sure the kernel doesn't place VMAs
there?  Do we respect mmap() hints that try to place memory there?

[toc] | [prev] | [next] | [standalone]

#1351840 — Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

On Mon, Mar 7, 2016 at 9:46 AM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
> On 03/07/2016 08:06 AM, Khalid Aziz wrote:
>> Top 4-bits of sparc64 virtual address are used for version tag only when
>> a process has its PSTATE.mcde bit set and it is accessing a memory
>> region that has ADI enabled on it (TTE.mcd set) and a version tag was
>> set on the virtual address being accessed. These 4-bits retain their
>> original semantics in all other cases.
>
> OK, so this effectively reduces the address space of a process using the
> feature.  Do we need to do anything explicit to keep an app from using
> that address space?  Do we make sure the kernel doesn't place VMAs
> there?  Do we respect mmap() hints that try to place memory there?

Also, what happens when someone does this to an aliased page?  This
could be a MAP_SHARED mapping or a not-yet-COWed MAP_ANONYMOUS
mapping.

Also, what am I missing?  Tying these tags to the physical page seems
like a poor design to me.  This seems really awkward to use.

-- 
Andy Lutomirski
AMA Capital Management, LLC

[toc] | [prev] | [next] | [standalone]

#1351858

On 03/07/2016 09:53 AM, Andy Lutomirski wrote:
> Also, what am I missing?  Tying these tags to the physical page seems
> like a poor design to me.  This seems really awkward to use.

Yeah, can you describe the structures that store these things?  Surely
the hardware has some kind of lookup tables for them and stores them in
memory _somewhere_.

[toc] | [prev] | [next] | [standalone]

#1351874

On 03/07/2016 11:12 AM, Dave Hansen wrote:
> On 03/07/2016 09:53 AM, Andy Lutomirski wrote:
>> Also, what am I missing?  Tying these tags to the physical page seems
>> like a poor design to me.  This seems really awkward to use.
>
> Yeah, can you describe the structures that store these things?  Surely
> the hardware has some kind of lookup tables for them and stores them in
> memory _somewhere_.
>

Version tags are tied to virtual addresses, not physical pages.

Where exactly are the tags stored is part of processor architecture and 
I am not privy to that. MMU stores these lookup tables somewhere and 
uses it to authenticate access to virtual addresses. It really is 
irrelevant to kernel how MMU implements access controls as long as we 
have access to the knowledge of how to use it.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1351884 — Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

On Mon, Mar 7, 2016 at 10:39 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote:
> On 03/07/2016 11:12 AM, Dave Hansen wrote:
>>
>> On 03/07/2016 09:53 AM, Andy Lutomirski wrote:
>>>
>>> Also, what am I missing?  Tying these tags to the physical page seems
>>> like a poor design to me.  This seems really awkward to use.
>>
>>
>> Yeah, can you describe the structures that store these things?  Surely
>> the hardware has some kind of lookup tables for them and stores them in
>> memory _somewhere_.
>>
>
> Version tags are tied to virtual addresses, not physical pages.
>
> Where exactly are the tags stored is part of processor architecture and I am
> not privy to that. MMU stores these lookup tables somewhere and uses it to
> authenticate access to virtual addresses. It really is irrelevant to kernel
> how MMU implements access controls as long as we have access to the
> knowledge of how to use it.
>

Can you translate this for people who don't know all the SPARC acronyms?

x86 has an upcoming feature called protection keys.  A page of virtual
memory has a protection key, which is a number from 0 through 16.  The
master copy is in the PTE, i.e. page table entry, which is a
software-managed data structure in memory and is exactly the thing
that Linux calls "pte".  The processor can cache that value in the TLB
(translation lookaside buffer), which is a hardware cache that caches
PTEs.  On access to a page of virtual memory, the processor does a
certain calculation involving a new register called PKRU and the
protection key and may deny access.

Hopefully that description makes sense even to people completely
unfamiliar with x86.

Can you try something similar for SPARC?  So far I'm lost, because
you've said that the ADI tag is associated with a VA, but it has to
match for aliases, and you've mentioned a bunch of acronyms, and I
have no clue what's going on.

--Andy

[toc] | [prev] | [next] | [standalone]

#1351901

From: Andy Lutomirski <luto@amacapital.net>
Date: Mon, 7 Mar 2016 10:53:23 -0800

> x86 has an upcoming feature called protection keys.  A page of virtual
> memory has a protection key, which is a number from 0 through 16.  The
> master copy is in the PTE, i.e. page table entry, which is a
> software-managed data structure in memory and is exactly the thing
> that Linux calls "pte".  The processor can cache that value in the TLB
> (translation lookaside buffer), which is a hardware cache that caches
> PTEs.  On access to a page of virtual memory, the processor does a
> certain calculation involving a new register called PKRU and the
> protection key and may deny access.

ADI is similar, except the "keys" (or "tags") are stored externally
rather than in the PTEs.  A bit in the PTE is used to enable tag match
checking.

The tags live in an external table, which is populated by ASI store
instructions.  The location of the table is implementation specific,
it could be hypervisor or CPU managed, but if stored in memory it is
to a region of memory accessible only to the hypervisor at best.

Khalid, maybe you should share notes with the folks working on x86
protection keys.

[toc] | [prev] | [next] | [standalone]

#1351915

On 03/07/2016 12:22 PM, David Miller wrote:
> Khalid, maybe you should share notes with the folks working on x86
> protection keys.
>

Good idea. Sparc ADI feature is indeed similar to x86 protection keys 
sounds like.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1352032

On 03/07/2016 11:46 AM, Khalid Aziz wrote:
> On 03/07/2016 12:22 PM, David Miller wrote:
>> Khalid, maybe you should share notes with the folks working on x86
>> protection keys.
> 
> Good idea. Sparc ADI feature is indeed similar to x86 protection keys
> sounds like.

There are definitely some similarities.  But protection keys doesn't
have any additional tables in which to keep metadata.  It keeps all of
its data in the page tables.  It also doesn't have an impact on the
virtual address layout.

But, it does have metadata to store in the VMA, has a special
siginfo->si_code, and it uses mprotect() (although a new pkey_mprotect()
variant that takes an extra argument).

Protection Keys are described a bit more here:

> http://git.kernel.org/cgit/linux/kernel/git/daveh/x86-pkeys.git/tree/Documentation/x86/protection-keys.txt?h=pkeys-v025&id=1b5b8a8836de8eb667027178b4820665dea5a038

MPX is another Intel feature separate from protection keys, but *it* has
some tables that it keep its metadata memory and special special
instructions to move metadata in and out of it.  It also has a prctl()
to enable/disable kernel assistance for the feature.  Unlike ADI, the
tables are exposed (and accessible) to user applications in normal
application memory.

MPX's documentation is here:

> http://git.kernel.org/cgit/linux/kernel/git/daveh/x86-pkeys.git/tree/Documentation/x86/intel_mpx.txt

Overall, I'm not seeing much overlap at all between the features, honestly.

[toc] | [prev] | [next] | [standalone]

#1352536

On 03/07/2016 10:39 AM, Khalid Aziz wrote:
> On 03/07/2016 11:12 AM, Dave Hansen wrote:
>> On 03/07/2016 09:53 AM, Andy Lutomirski wrote:
>>> Also, what am I missing?  Tying these tags to the physical page seems
>>> like a poor design to me.  This seems really awkward to use.
>>
>> Yeah, can you describe the structures that store these things? Surely
>> the hardware has some kind of lookup tables for them and stores them in
>> memory _somewhere_.
>>
>
> Version tags are tied to virtual addresses, not physical pages.
>
> Where exactly are the tags stored is part of processor architecture 
> and I am not privy to that. MMU stores these lookup tables somewhere 
> and uses it to authenticate access to virtual addresses. It really is 
> irrelevant to kernel how MMU implements access controls as long as we 
> have access to the knowledge of how to use it.

The tags are stored in physical memory, and you can write a tag directly 
to that memory via stxa with ASI_MCD_REAL and completely bypass the MMU. 
When you do that, the tag will still be seen by any virtual address that 
maps to that physical address.

Rob

[toc] | [prev] | [next] | [standalone]

#1351990

On 03/07/2016 10:46 AM, Dave Hansen wrote:
> On 03/07/2016 08:06 AM, Khalid Aziz wrote:
>> Top 4-bits of sparc64 virtual address are used for version tag only when
>> a process has its PSTATE.mcde bit set and it is accessing a memory
>> region that has ADI enabled on it (TTE.mcd set) and a version tag was
>> set on the virtual address being accessed. These 4-bits retain their
>> original semantics in all other cases.
>
> OK, so this effectively reduces the address space of a process using the
> feature.  Do we need to do anything explicit to keep an app from using
> that address space?  Do we make sure the kernel doesn't place VMAs
> there?  Do we respect mmap() hints that try to place memory there?
>

Good questions. Isn't set of valid VAs already constrained by VA_BITS 
(set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we are 
already not using the top 4 bits. Please correct me if I am wrong.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1353362

From: Khalid Aziz <khalid.aziz@oracle.com>
Date: Mon, 7 Mar 2016 14:06:43 -0700

> Good questions. Isn't set of valid VAs already constrained by VA_BITS
> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
> are already not using the top 4 bits. Please correct me if I am wrong.

Another limiting constraint is the number of address bits coverable by
the 4-level page tables we use.  And this is sign extended so we have
a top-half and a bottom-half with a "hole" in the center of the VA
space.

I want some clarification on the top bits during ADI accesses.

If ADI is enabled, then the top bits of the virtual address are
intepreted as tag bits.  Once "verified" with the ADI settings, what
happense to these tag bits?  Are they dropped from the virtual address
before being passed down the TLB et al. for translations?

If not, then this means you have to map ADI memory to the correct
location so that the tags match up.

And if that's the case, if you really wanted to mix tags within a
single page, you'd have to map that page several times, once for each
and every cacheline granular tag you'd like to use within that page.

[toc] | [prev] | [next] | [standalone]

#1353380

On 03/08/2016 12:57 PM, David Miller wrote:
> From: Khalid Aziz <khalid.aziz@oracle.com>
> Date: Mon, 7 Mar 2016 14:06:43 -0700
>
>> Good questions. Isn't set of valid VAs already constrained by VA_BITS
>> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
>> are already not using the top 4 bits. Please correct me if I am wrong.
>
> Another limiting constraint is the number of address bits coverable by
> the 4-level page tables we use.  And this is sign extended so we have
> a top-half and a bottom-half with a "hole" in the center of the VA
> space.
>
> I want some clarification on the top bits during ADI accesses.
>
> If ADI is enabled, then the top bits of the virtual address are
> intepreted as tag bits.  Once "verified" with the ADI settings, what
> happense to these tag bits?  Are they dropped from the virtual address
> before being passed down the TLB et al. for translations?

Bits 63-60 (tag bits) are dropped from the virtual address before being 
passed down the TLB for translation when PSTATE.mcde = 1.

--
Khalid

>
> If not, then this means you have to map ADI memory to the correct
> location so that the tags match up.
>
> And if that's the case, if you really wanted to mix tags within a
> single page, you'd have to map that page several times, once for each
> and every cacheline granular tag you'd like to use within that page.
>

[toc] | [prev] | [next] | [standalone]

#1353381

From: Khalid Aziz <khalid.aziz@oracle.com>
Date: Tue, 8 Mar 2016 13:16:11 -0700

> On 03/08/2016 12:57 PM, David Miller wrote:
>> From: Khalid Aziz <khalid.aziz@oracle.com>
>> Date: Mon, 7 Mar 2016 14:06:43 -0700
>>
>>> Good questions. Isn't set of valid VAs already constrained by VA_BITS
>>> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
>>> are already not using the top 4 bits. Please correct me if I am wrong.
>>
>> Another limiting constraint is the number of address bits coverable by
>> the 4-level page tables we use.  And this is sign extended so we have
>> a top-half and a bottom-half with a "hole" in the center of the VA
>> space.
>>
>> I want some clarification on the top bits during ADI accesses.
>>
>> If ADI is enabled, then the top bits of the virtual address are
>> intepreted as tag bits.  Once "verified" with the ADI settings, what
>> happense to these tag bits?  Are they dropped from the virtual address
>> before being passed down the TLB et al. for translations?
> 
> Bits 63-60 (tag bits) are dropped from the virtual address before
> being passed down the TLB for translation when PSTATE.mcde = 1.

Ok and you said that values 15 and 0 are special.

I'm just wondering if this means you can't really use ADI mappings in
the top half of the 64-bit address space.  If the bits are dropped, they
will be zero, but they need to be all 1's for the top-half of the VA
space since it's sign extended.

[toc] | [prev] | [next] | [standalone]

#1353409

On 03/08/2016 01:27 PM, David Miller wrote:
> From: Khalid Aziz <khalid.aziz@oracle.com>
> Date: Tue, 8 Mar 2016 13:16:11 -0700
>
>> On 03/08/2016 12:57 PM, David Miller wrote:
>>> From: Khalid Aziz <khalid.aziz@oracle.com>
>>> Date: Mon, 7 Mar 2016 14:06:43 -0700
>>>
>>>> Good questions. Isn't set of valid VAs already constrained by VA_BITS
>>>> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
>>>> are already not using the top 4 bits. Please correct me if I am wrong.
>>>
>>> Another limiting constraint is the number of address bits coverable by
>>> the 4-level page tables we use.  And this is sign extended so we have
>>> a top-half and a bottom-half with a "hole" in the center of the VA
>>> space.
>>>
>>> I want some clarification on the top bits during ADI accesses.
>>>
>>> If ADI is enabled, then the top bits of the virtual address are
>>> intepreted as tag bits.  Once "verified" with the ADI settings, what
>>> happense to these tag bits?  Are they dropped from the virtual address
>>> before being passed down the TLB et al. for translations?
>>
>> Bits 63-60 (tag bits) are dropped from the virtual address before
>> being passed down the TLB for translation when PSTATE.mcde = 1.
>
> Ok and you said that values 15 and 0 are special.
>
> I'm just wondering if this means you can't really use ADI mappings in
> the top half of the 64-bit address space.  If the bits are dropped, they
> will be zero, but they need to be all 1's for the top-half of the VA
> space since it's sign extended.
>

According to the manual when PSTATE.mcde=1, bits 63:60 of the virtual 
address of any load or store (using virtual address) are masked before 
being sent to memory system which includes MMU. Hardware TSB walker 
masks bits 63:60 and then sign extends from bit 59 before generating TSB 
pointer and before comparison to TSB TTE VAs but the virtual address in 
the TTE tag that is written to DTLB is masked and not sign extended. 
Manual also states that for implementations that fully support 60 bits 
or more of virtual address, they must sign-extend virtual address in TSB 
TTE tag.

--
Khalid

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web