From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:37452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr6c4-0006Am-MP for qemu-devel@nongnu.org; Tue, 05 Feb 2019 14:42:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gr6c3-00074N-Go for qemu-devel@nongnu.org; Tue, 05 Feb 2019 14:42:32 -0500 Received: from mail-ot1-x342.google.com ([2607:f8b0:4864:20::342]:41422) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gr6c3-00073N-7T for qemu-devel@nongnu.org; Tue, 05 Feb 2019 14:42:31 -0500 Received: by mail-ot1-x342.google.com with SMTP id u16so7805692otk.8 for ; Tue, 05 Feb 2019 11:42:30 -0800 (PST) MIME-Version: 1.0 References: <20190114011122.5995-1-richard.henderson@linaro.org> In-Reply-To: <20190114011122.5995-1-richard.henderson@linaro.org> From: Peter Maydell Date: Tue, 5 Feb 2019 19:42:18 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH 00/17] target/arm: Implement ARMv8.5-MemTag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: QEMU Developers , qemu-arm , Ramana Radhakrishnan , Will Deacon , Dave P Martin , szabolcs.nagy@arm.com, Catalin Marinas , Mark Rutland On Mon, 14 Jan 2019 at 01:11, Richard Henderson wrote: > > Based-on: 20190110124951.15473-1-richard.henderson@linaro.org > aka the TBID patch set, which itself is based on the BTI patch set. > > The full tree is available at > > https://github.org/rth7680/qemu.git tgt-arm-mte > > This extension isl also spelled MTE in the ARM. > > This patch set only attempts to implement linux-user emulation. > For system emulation, I still miss the new cache flushing insns (easy) > and the out-of-band physical memory for the allocation tags (harder). > > From a few mis-steps in writing the test cases for the extension, > I might suggest that some future kernel's userland ABI for this have > TCR.TCMA0 = 1, so that legacy code that is *not* MTE aware can use > a frame pointer without accidentally tripping left over stack tags. > (As seen in patch 5, SP+OFF is unchecked per the ISA but FP+OFF is not.) > > OTOH, depending on the application, that does make it easier for an > attack vector to clean the tag off the top of a pointer to bypass > store checking. So, tricky. I'm working through review of this, but feel free to rebase on current master (which has now got a pile of your other patches in it, since I've just merged target-arm.next) without waiting for me to finish going through it. thanks -- PMM