Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753388AbcCGSu2 (ORCPT ); Mon, 7 Mar 2016 13:50:28 -0500 Received: from mail-oi0-f41.google.com ([209.85.218.41]:36163 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752966AbcCGSuS (ORCPT ); Mon, 7 Mar 2016 13:50:18 -0500 MIME-Version: 1.0 In-Reply-To: <56DDC6E0.4000907@oracle.com> References: <1456951177-23579-1-git-send-email-khalid.aziz@oracle.com> <20160305.230702.1325379875282120281.davem@davemloft.net> <56DD9949.1000106@oracle.com> <20160307.115626.807716799249471744.davem@davemloft.net> <56DDC2B6.6020009@oracle.com> <56DDC6E0.4000907@oracle.com> From: Andy Lutomirski Date: Mon, 7 Mar 2016 10:49:57 -0800 Message-ID: Subject: Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) To: Khalid Aziz Cc: David Miller , Jonathan Corbet , Andrew Morton , dingel@linux.vnet.ibm.com, bob.picco@oracle.com, "Kirill A. Shutemov" , "Aneesh Kumar K.V" , Andrea Arcangeli , Arnd Bergmann , sparclinux@vger.kernel.org, Rob Gardner , Michal Hocko , chris.hyser@oracle.com, Richard Weinberger , Vlastimil Babka , Konstantin Khlebnikov , Oleg Nesterov , Greg Thelen , Jan Kara , xiexiuqi@huawei.com, Vineet.Gupta1@synopsys.com, Andrew Lutomirski , "Eric W. Biederman" , Benjamin Segall , Geert Uytterhoeven , Davidlohr Bueso , Alexey Dobriyan , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , linux-arch , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2587 Lines: 81 On Mon, Mar 7, 2016 at 10:22 AM, Khalid Aziz wrote: > On 03/07/2016 11:08 AM, Andy Lutomirski wrote: >> >> On Mon, Mar 7, 2016 at 10:04 AM, Khalid Aziz >> wrote: >>> >>> On 03/07/2016 09:56 AM, David Miller wrote: >>>> >>>> >>>> From: Khalid Aziz >>>> 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