Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4164869yba; Tue, 9 Apr 2019 12:34:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOxvg8JURXVSZl1kxR48/8lBwICt9GiNRYGBGdWJVfmFlgUWp92Ozbs7Tb85IEkTufY5I7 X-Received: by 2002:a63:ef09:: with SMTP id u9mr36640131pgh.126.1554838478197; Tue, 09 Apr 2019 12:34:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554838478; cv=none; d=google.com; s=arc-20160816; b=POvNMBGWzo6n7EM7lpjEDmWKBVn4wWEtBwmHxBUMAh4uTXi9K7c7KxcCzGH7btnj0A SwOtOtPAlssdoj58rcdJ/mf42fDgFHpE0grXChnQgkzCxfDTinWIRCOwhgTWYPcqNz/A RpCXVYWOSpKjrdJeaRqJHiNNeyJYcfLl/faA8J2weor60fESCMBHG80qt5VaLrtUTU0h 5yL+CewUnWR49B5vUqIjX5QTEnab8w+IL30jKIYfoAFaCCA5xkbbwYPFKS9Erd0iMqKV BvttTM3l6jj109LvXdJGfUlmOJ2Cmf0XDc3l6YagbNM5PCF/+7fNI+Lcmu5YvfiE1+WM CYog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-topic:thread-index :content-transfer-encoding:mime-version:subject:message-id:cc:to :from:date:dkim-signature:dkim-filter; bh=RgIdMsNYziUUgB3yzbunxiCN3VtyEeBtcNKkrJl49l4=; b=DaaMJ9udXkTB6uJhPAyiPqC0c9NKebEXtYyLU155n0bfHwijGou+Z/U1MKwQClmXsP QSvxA/pvvSpqjbJu6yMr6LYezc+dvpLdKBoFLQV6QZJJw8ThGrOgLoYovrtrvfsHXhtG 91vfbjsUav2JrCcPObXPsSpZekX5TwsUVj7KEg+LBIFp0dbdwltP22KxCXFnJt5739Fb 3uFNs7mfO6uKsGfGzODC6ATCVSn2HnonlWv7jQABVtO5vpcYJ3uTyxxEpsguIMnIKkKJ RnQtEmu34VC5Afn4qx8UmjQNApH3N5X5qql+unUQRDGlWqTtOnJ0qlV6aKxwrCoPoheP 1e3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=Q+Fk1gzm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y191si29163159pgd.218.2019.04.09.12.34.22; Tue, 09 Apr 2019 12:34:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=Q+Fk1gzm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726680AbfDITc0 (ORCPT + 99 others); Tue, 9 Apr 2019 15:32:26 -0400 Received: from mail.efficios.com ([167.114.142.138]:49606 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726627AbfDITcY (ORCPT ); Tue, 9 Apr 2019 15:32:24 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 2E64E1D32ED; Tue, 9 Apr 2019 15:32:23 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id vUSNMqrH-hYw; Tue, 9 Apr 2019 15:32:22 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id D8D9F1D32EA; Tue, 9 Apr 2019 15:32:22 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com D8D9F1D32EA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1554838342; bh=RgIdMsNYziUUgB3yzbunxiCN3VtyEeBtcNKkrJl49l4=; h=Date:From:To:Message-ID:MIME-Version; b=Q+Fk1gzmWprLvC67Ap78hQObBTPczaRtLbtMTIMkYcfKeNg76aTZr1tO73DLqxz26 fmCgoIgK/FHh21et5Ot02xZciVt1uJhRX5jyoy5qM2ZLA5UjmqjWGLH11jsb49ZHw3 4+NxHEmUHfGa5pz89HAjvVoiQ9RpFveJKsw3YBjBfQvkrzHh/xR0vqQzLQjOqrJjMz R8pd0SGIVvoHqM5N+GxKr3DLyEgshtveCZTVDXM1ue+vuQ4nnIiu0NEehPO09FyG3n cT3hHZ3g/lho2fjaYi1xsAIKywRAqQUAp3b5NevLc4rt2AaU1KGaG03BQL87B2Q0Af ucEh5DnujWl5g== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 7OrR7bAUYm1Y; Tue, 9 Apr 2019 15:32:22 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id B91E81D32DE; Tue, 9 Apr 2019 15:32:22 -0400 (EDT) Date: Tue, 9 Apr 2019 15:32:22 -0400 (EDT) From: Mathieu Desnoyers To: heiko carstens , schwidefsky , gor Cc: libc-alpha , linux-kernel , Carlos O'Donell Message-ID: <1779981820.2626.1554838342731.JavaMail.zimbra@efficios.com> Subject: rseq/s390: choosing code signature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.12_GA_3794 (ZimbraWebClient - FF66 (Linux)/8.8.12_GA_3794) Thread-Index: rw0yh+TLA/QoEMPFAX3xNuasWSgKdA== Thread-Topic: rseq/s390: choosing code signature Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, We are about to include the code signature required prior to restartable sequences abort handlers into glibc, which will make this ABI choice final. We need architecture maintainer input on that signature value. That code signature is placed before each abort handler, so the kernel can validate that it is indeed jumping to an abort handler (and not some arbitrary attacker-chosen code). The signature is never executed. The current discussion thread on the glibc mailing list leads us towards using a trap with uncommon immediate operand, which simplifies integration with disassemblers, emulators, makes it easier to debug if the control flow gets redirected there by mistake, and is nicer for some architecture's speculative execution. We can have different signatures for each sub-architecture, as long as they don't have to co-exist within the same process. We can special-case with #ifdef for each sub-architecture and endianness if need be. If the architecture has instruction set extensions that can co-exist with the architecture instruction set within the same process, we need to take into account to which instruction the chosen signature value would map (and possibly decide if we need to extend rseq to support many signatures). Here is an example of rseq signature definition template: /* * TODO: document trap instruction objdump output on each sub-architecture * instruction sets, as well as instruction set extensions. */ #define RSEQ_SIG 0x######## Ideally we'd need a patch on top of the Linux kernel tools/testing/selftests/rseq/rseq-s390.h file that updates the signature value, so I can then pick it up for the glibc patchset. Thanks! Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com