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

Groups > linux.kernel > #1726169 > unrolled thread

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

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 v7 9/9] sparc64: Add support for ADI (Application Data  Integrity) Pavel Machek <pavel@ucw.cz> - 2017-09-04 18:30 +0200
    Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data  Integrity) David Miller <davem@davemloft.net> - 2017-09-05 23:50 +0200
      Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data  Integrity) Pavel Machek <pavel@ucw.cz> - 2017-09-07 00:40 +0200
        Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data  Integrity) Steven Sistare <steven.sistare@oracle.com> - 2017-09-08 14:30 +0200
    Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data  Integrity) Khalid Aziz <khalid.aziz@oracle.com> - 2017-09-06 16:20 +0200

#1726169 — Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Multipart message — attachments visible in raw view] — view raw

Hi!

> ADI is a new feature supported on SPARC M7 and newer processors to allow
> hardware to catch rogue accesses to memory. ADI is supported for data
> fetches only and not instruction fetches. An app can enable ADI on its
> data pages, set version tags on them and use versioned addresses to
> access the data pages. Upper bits of the address contain the version
> tag. On M7 processors, upper four bits (bits 63-60) contain the version
> tag. If a rogue app attempts to access ADI enabled data pages, its
> access is blocked and processor generates an exception. Please see
> Documentation/sparc/adi.txt for further details.

I'm afraid I still don't understand what this is meant to prevent.

IOMMU ignores these, so this is not to prevent rogue DMA from doing
bad stuff.

Will gcc be able to compile code that uses these automatically? That
does not sound easy to me. Can libc automatically use this in malloc()
to prevent accessing freed data when buffers are overrun?

Is this for benefit of JITs?

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]

#1727007

From: Pavel Machek <pavel@ucw.cz>
Date: Mon, 4 Sep 2017 18:25:30 +0200

> Will gcc be able to compile code that uses these automatically? That
> does not sound easy to me. Can libc automatically use this in malloc()
> to prevent accessing freed data when buffers are overrun?
> 
> Is this for benefit of JITs?

Anything that can control mappings and the virtual address used to
access memory can use ADI.

malloc() is of course one such case.  It can map memory with ADI
enabled, and return buffer addresses to malloc() callers with the
proper virtual address bits set to satisfy the ADI key checks.

And by induction anything using malloc() for it's memory allocation
gets ADI protection as well.

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

#1727796

[Multipart message — attachments visible in raw view] — view raw

On Tue 2017-09-05 14:44:56, David Miller wrote:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Mon, 4 Sep 2017 18:25:30 +0200
> 
> > Will gcc be able to compile code that uses these automatically? That
> > does not sound easy to me. Can libc automatically use this in malloc()
> > to prevent accessing freed data when buffers are overrun?
> > 
> > Is this for benefit of JITs?
> 
> Anything that can control mappings and the virtual address used to
> access memory can use ADI.
> 
> malloc() is of course one such case.  It can map memory with ADI
> enabled, and return buffer addresses to malloc() callers with the
> proper virtual address bits set to satisfy the ADI key checks.
> 
> And by induction anything using malloc() for it's memory allocation
> gets ADI protection as well.

I see; that's actually quite a nice trick.

I guess it does not protect against stack-based overflows, but should
help against heap-based overflows, so it improves security a bit, too.

Nice, thanks for explanation.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

#1728788

On 9/6/2017 6:32 PM, Pavel Machek wrote:
> On Tue 2017-09-05 14:44:56, David Miller wrote:
>> From: Pavel Machek <pavel@ucw.cz>
>> Date: Mon, 4 Sep 2017 18:25:30 +0200
>>
>>> Will gcc be able to compile code that uses these automatically? That
>>> does not sound easy to me. Can libc automatically use this in malloc()
>>> to prevent accessing freed data when buffers are overrun?
>>>
>>> Is this for benefit of JITs?
>>
>> Anything that can control mappings and the virtual address used to
>> access memory can use ADI.
>>
>> malloc() is of course one such case.  It can map memory with ADI
>> enabled, and return buffer addresses to malloc() callers with the
>> proper virtual address bits set to satisfy the ADI key checks.
>>
>> And by induction anything using malloc() for it's memory allocation
>> gets ADI protection as well.
> 
> I see; that's actually quite a nice trick.
> 
> I guess it does not protect against stack-based overflows, but should
> help against heap-based overflows, so it improves security a bit, too.
> 
> Nice, thanks for explanation.

ADI can also be used to protect the stack.  Modify ADI versions for
a 64B aligned portion of the register save area in the kernel spill
and fill handlers,  and accidental or malicious access to the area 
from userland will trap.  Other data on the stack can be corrupted, 
but one cannot linearly overflow into the next stack frame without 
tripping over the ADI canary.  There are a few other details to handle,
such as setjmp/longjmp and JITs that modify the stack, but that is the gist.  
This is not part of the current patch, but has been implemented on
Solaris.

ADI could protect other data on the stack, but that requires 
compiler code generation changes.

- Steve

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

#1727537

On 09/04/2017 10:25 AM, Pavel Machek wrote:
> Hi!
> 
>> ADI is a new feature supported on SPARC M7 and newer processors to allow
>> hardware to catch rogue accesses to memory. ADI is supported for data
>> fetches only and not instruction fetches. An app can enable ADI on its
>> data pages, set version tags on them and use versioned addresses to
>> access the data pages. Upper bits of the address contain the version
>> tag. On M7 processors, upper four bits (bits 63-60) contain the version
>> tag. If a rogue app attempts to access ADI enabled data pages, its
>> access is blocked and processor generates an exception. Please see
>> Documentation/sparc/adi.txt for further details.
> 
> I'm afraid I still don't understand what this is meant to prevent.
> 
> IOMMU ignores these, so this is not to prevent rogue DMA from doing
> bad stuff.
> 
> Will gcc be able to compile code that uses these automatically? That
> does not sound easy to me. Can libc automatically use this in malloc()
> to prevent accessing freed data when buffers are overrun?
> 
> Is this for benefit of JITs?
> 

David explained it well. Yes, preventing buffer overflow is one of the 
uses of ADI. Protecting critical data from wild writes caused by 
programming errors is another use. ADI can be used for debugging as well 
during development.

Thanks,
Khalid

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web