From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by kanga.kvack.org (Postfix) with ESMTP id 0B2956B0253 for ; Mon, 7 Mar 2016 14:54:38 -0500 (EST) Received: by mail-oi0-f52.google.com with SMTP id m82so87261746oif.1 for ; Mon, 07 Mar 2016 11:54:38 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com. [2607:f8b0:4003:c06::22f]) by mx.google.com with ESMTPS id t191si4082900oif.58.2016.03.07.11.54.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Mar 2016 11:54:36 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id d205so87320195oia.0 for ; Mon, 07 Mar 2016 11:54:36 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <56DDDA31.9090105@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> <56DDDA31.9090105@oracle.com> From: Andy Lutomirski Date: Mon, 7 Mar 2016 11:54:16 -0800 Message-ID: Subject: Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI) Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: 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 On Mon, Mar 7, 2016 at 11:44 AM, Khalid Aziz wrote: > On 03/07/2016 11:49 AM, Andy Lutomirski wrote: >> >> On Mon, Mar 7, 2016 at 10:22 AM, Khalid Aziz >> wrote: >>> >>> 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? >> > > Consider this scenario: > > 1. Process A creates a shm and attaches to it. > 2. Process A fills shm with data it wants to share with only known > processes. It enables ADI and sets tags on the shm. > 3. Hacker triggers something like stack overflow on process A, exec's a new > rogue binary and manages to attach to this shm. MMU knows tags were set on > the virtual address mapping to the physical pages hosting the shm. If MMU > does not require the rogue process to set the exact same tags on its mapping > of the same shm, rogue process has defeated the ADI protection easily. > > Does this make sense? This makes sense, but I still think the design is poor. If the hacker gets code execution, then they can trivially brute force the ADI bits. Also, if this is the use case in mind, shouldn't the ADI bits bet set on the file, not the mapping? E.g. have an ioctl on the shmfs file that sets its ADI bits? > >>> >>>> >>>> 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. >> > > A process can not just write version tags and make the file inaccessible to > others. It takes three steps to enable ADI: > > 1. Set PSTATE.mcde for the process. > 2. Set TTE.mcd on all PTEs for the virtual addresses ADI is being enabled > on. > 3. Set version tags. > > Unless all three steps are taken, tag checking will not be done. stxa will > fail unless step 2 is completed. In your example, the step of setting > TTE.mcd will force sharing to stop for the process through > change_protection(), right? OK, that makes some sense. Can a shared page ever have TTE.mcd set? How does one share a page, even deliberately, between two processes with cmd set? --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org