lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Mar 2016 10:49:57 -0800 From: Andy Lutomirski <luto@...capital.net> To: Khalid Aziz <khalid.aziz@...cle.com> Cc: David Miller <davem@...emloft.net>, Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>, dingel@...ux.vnet.ibm.com, bob.picco@...cle.com, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>, Andrea Arcangeli <aarcange@...hat.com>, Arnd Bergmann <arnd@...db.de>, sparclinux@...r.kernel.org, Rob Gardner <rob.gardner@...cle.com>, Michal Hocko <mhocko@...e.cz>, chris.hyser@...cle.com, Richard Weinberger <richard@....at>, Vlastimil Babka <vbabka@...e.cz>, Konstantin Khlebnikov <koct9i@...il.com>, Oleg Nesterov <oleg@...hat.com>, Greg Thelen <gthelen@...gle.com>, Jan Kara <jack@...e.cz>, xiexiuqi@...wei.com, Vineet.Gupta1@...opsys.com, Andrew Lutomirski <luto@...nel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Benjamin Segall <bsegall@...gle.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, Davidlohr Bueso <dave@...olabs.net>, Alexey Dobriyan <adobriyan@...il.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, linux-arch <linux-arch@...r.kernel.org>, Linux API <linux-api@...r.kernel.org> Subject: Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) On Mon, Mar 7, 2016 at 10:22 AM, Khalid Aziz <khalid.aziz@...cle.com> wrote: > On 03/07/2016 11:08 AM, Andy Lutomirski wrote: >> >> On Mon, Mar 7, 2016 at 10:04 AM, Khalid Aziz <khalid.aziz@...cle.com> >> wrote: >>> >>> On 03/07/2016 09:56 AM, David Miller wrote: >>>> >>>> >>>> From: Khalid Aziz <khalid.aziz@...cle.com> >>>> Date: Mon, 7 Mar 2016 08:07:53 -0700 >>>> >>>>> PR_GET_SPARC_ADICAPS >>>> >>>> >>>> >>>> Put this into a new ELF auxiliary vector entry via ARCH_DLINFO. >>>> >>>> So now all that's left is supposedly the TAG stuff, please explain >>>> that to me so I can direct you to the correct existing interface to >>>> provide that as well. >>>> >>>> Really, try to avoid prtctl, it's poorly typed and almost worse than >>>> ioctl(). >>>> >>> >>> The two remaining operations I am looking at are: >>> >>> 1. Is PSTATE.mcde bit set for the process? PR_SET_SPARC_ADI provides this >>> in >>> its return value in the patch I sent. >>> >>> 2. Is TTE.mcd set for a given virtual address? PR_GET_SPARC_ADI_STATUS >>> provides this function in the patch I sent. >>> >>> Setting and clearing version tags can be done entirely from userspace: >>> >>> while (addr < end) { >>> asm volatile( >>> "stxa %1, [%0]ASI_MCD_PRIMARY\n\t" >>> : >>> : "r" (addr), "r" (version)); >>> addr += adicap.blksz; >>> } >>> so I do not have to add any kernel code for tags. >> >> >> Is the effect of that to change the tag associated with a page to >> which the caller has write access? > > > No, it changes the tag associated with the virtual address for the caller. > Physical page backing this virtual address is unaffected. Tag checking is > done for virtual addresses. The one restriction where physical address is > relevant is when two processes map the same physical page, they both have to > use the same tag for the virtual addresses that map on to the shared > physical pages. Slow down, please. *Why* do the tags for two different VAs that map to the same PA have to match? What goes wrong if they don't, and why is requiring them to be the same a good idea? > >> >> I sense DoS issues in your future. >> > > Are you concerned about DoS even if the tag is associated with virtual > address, not physical address? Yes, absolutely. fd = open("/lib/ld.so"); mmap(fd) stxa to write the tag *boom*, presumably, because the tags apparently have to match for all mappings. What data structure or structures changes when this stxa instruction happens? --Andy
Powered by blists - more mailing lists