From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E573F1F461 for ; Thu, 18 Jul 2019 19:49:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-id:content-transfer-encoding :mime-version; q=dns; s=default; b=v54fhlFXuMAo34geZe+HzgkI4r1Iy SKLfXllNWNSEqDtgEiBKz8Lm5qV2WkbphEwUzQAR/TXROcG2hlV1cTuKq0DqzZG6 mIO/IKPvMP+kHE4/Fa619lJOgqQ56Hbto1oVIA698tWyyoavxI2pFFLKUzFjHmkv UriJ2ELN3gmHNk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:references :in-reply-to:content-type:content-id:content-transfer-encoding :mime-version; s=default; bh=gRl/SEyjzjGIH8uTNZtPIw4bDkI=; b=d/Q +v5egDbkbsEDKqjY4v7LAr0H7+iilZTCLPvFIpYJ1kHH/gHch1kUkhMsarZOm5xT ollGvlkQN5LEhdDBi+jM78wIDVo8ivZHE44hlccNJCpy7Zfmuxguv1n9AZyosGq5 Db3g8Tz3w9ZvJvpQIBrdY0S/6Wk+8zNg9Juj8F9k= Received: (qmail 38759 invoked by alias); 18 Jul 2019 19:49:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 38746 invoked by uid 89); 18 Jul 2019 19:49:14 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: NAM02-BL2-obe.outbound.protection.outlook.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q2BwzsVnBLCdI9P9ee+XrN/FPDsW17QzRNs26OOuAHTXohdyd3Cb2O04IyBBFOM1t6Yj6w5Kxn+Wh9fmYc01/w1muyn/ypM1Ymf/A3MxhVSLapaShzrFL3J5WZWYXuJqIkjPOCRTS93JIIIUEBck9fHE1oE4XoGIq8KJuvt3iw1egyR4zaPEkVYoAfdrHKag1xbP6wCiM/clTzuHoAS2TdhnXeeGmk/kZqSyXn9zrA4LiqBcGDVhKxY3+71GJrxOYs0Qok6iE2tNMBL3moC/cwYhp/XAiM925nzII15S5NwQffvVoQVmfs2LfuSZ9EBrnWUldaz3hQIUSN72glT5Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=58kqgdGvgjHehO0op+DI1G98WUkcarUqrIriPmYE2FA=; b=J0lUCBvIXrEuwuStdD/vS16mccQqXBpt7Ojtxe7Dtzyxr7GV8Noy8sz+zJR6HVn57lcHRvkxn5pTTNZ5lUwQ1MzS6uHcXRkile4y76ErIwXFEYuM4UphAV8aOEyMm8/XkEcsDNMqY/m+bBlpJu0P9S7+pfkkilnBqBvGeqHtalBgPdhEZEHuL6N1RDKcjZV9M6UkjnykqbQ1eG5piRb/V//IRNcfyYHku7hTKp5dPTCXO1LJ/DURHp9U8uAmbkhj+xLW7jWU9Zu2od1eCFEtmaWmtpdsh1FIwKKVHxtSq/ORZpvV13nUNHmhHhkA8Tx3T9zPr6d1OAy+DIwMsil2+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=wavecomp.com;dmarc=pass action=none header.from=wavecomp.com;dkim=pass header.d=wavecomp.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wavesemi.onmicrosoft.com; s=selector1-wavesemi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=58kqgdGvgjHehO0op+DI1G98WUkcarUqrIriPmYE2FA=; b=A3+rD+oyhzqkRuMeLulCoFeyHaUpCRwizflo52s0j7xyzDF7hIIgN0hdiK1cxXexV0VTI8zu20VWWije/unidZVS+oTTxEUO2z6lWodvgkK3uGDOD36P5Bn1TGsBjZlDicGOBuQ0a3y0qttZkiDsL6bXgc4P8Co+7tjBBMYqC3U= From: Dragan Mladjenovic To: Adhemerval Zanella , Faraz Shahbazker , "libc-alpha@sourceware.org" CC: Joseph Myers , Carlos O'Donell , "Maciej W . Rozycki" Subject: Re: [PATCH v2 0/3] Mips support for PT_GNU_STACK Date: Thu, 18 Jul 2019 19:49:09 +0000 Message-ID: <5D30CD12.2090501@wavecomp.com> References: <1563214941-16203-1-git-send-email-dmladjenovic@wavecomp.com> In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmladjenovic@wavecomp.com; x-ms-oob-tlc-oobclassifiers: OLM:10000; received-spf: None (protection.outlook.com: wavecomp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dmladjenovic@wavecomp.com On 18.07.2019. 15:38, Adhemerval Zanella wrote: > > > On 17/07/2019 19:59, Faraz Shahbazker wrote: >> On 07/17/2019 12:43 PM, Adhemerval Zanella wrote: >>> I think checking the kernel version is the wrong approach, it prevents = a distribution >>> to backport the kernel fix without also applying a out-of-tree patch to= fix it on glibc >>> as well. IMHO the proper way would be to make kernel advertise it thro= ugh hwcap, as >>> other architectures do for similar kernel features and not tie it to an= y specific >>> version. >> >> The original proposal was to advertise through AT_FLAGS. I've heard this= suggestion of using >> hwcap from multiple sources, so I am curious - what other *purely* softw= are kernel features >> are advertised using hwcap? > > It is not common, but on powerpc has both PPC_FEATURE2_HTM_NOSC and > PPC_FEATURE2_HTM_NO_SUSPEND which is kernel behaviour regarding transacti= on > memory state and syscall execution. > >> >>>> The last patch increments the ABI Version number in order to disallow = new >>>> binaries to run with older glibc. The number is not set in stone. >>>> I'm assuming it will probably land after GNU_HASH [3] support which co= nsumes >>>> ABI version 5 for MIPS. I will send a proposal for Binutils and GCC af= ter this >>>> part gets finalized. >>> >>> If the idea is to fallback to executable stack for the case of underlyi= ng missing >>> kernel support, which is the net gain in adding this requirement? My un= derstanding >>> it ABI bump should be used to fail early for the cases where the new bi= naries >>> requires loader support that can not be provided (iFUNC or new relocati= ons), not >>> for hardening. >> >> It is not really hardening, the way glibc handles PT_GNU_STACK is along = the lines of >> 'may have non-executable stack' rather than 'must have non-executable st= ack'. However >> the MIPS backend overrides *any* incoming PT_GNU_STACK permissions using= the default (RWX) >> permissions for MIPS, in effect enforcing 'will not have non-executable = stack'. What is >> being indicated here is a change in this default behaviour. The ABI vers= ion bump would >> indicate whether PT_GNU_STACK permissions will be honoured (at least to = the extent it is >> by other architectures) or simply ignored (as it has historically been). >> >> IMO, the current behaviour of PT_GNU_STACK for MIPS is an anomaly in its= elf. What should >> have been, is a rejection of non-executable PT_GNU_STACK at some level, = instead of silently >> overriding it in glibc. So are you of the opinion that this change in gl= ibc behaviour is not >> worth being published at all, or that it should be advertised using a di= fferent mechanism >> instead of an ABI version bump? > > Since non-executable stack is tied with underlying kernel support rather = than > ABI, my suggestion is just to assume non-executable stack as default, wit= hout > permission override, if glibc is configure for kernel higher than 3.8. We= will > need to live with old behaviour for default builds. > If I follow correctly this can be simplified to either require 4.8=20 kernel when built with non-executable stack or force executable stack at=20 build time for default (< 4.8) builds? Just to be on the same page. This "old" behavior of overriding=20 PT_GNU_STACK permission to RWX on mips is introduced in the second patch=20 of the series. What I understand is that previously you could build a glibc with RW=20 PT_GNU_STACK and it may or may not work at runtime depending on if the=20 kernel actually needed to use you stack for emulation and if you=20 hardware is capable of enforcing NX page protection. If linker, glibc or kernel did historically disallow RW PT_GNU_STACK we=20 would not have this issue. I interpret this abi version bump more as assurance that we are not=20 running in the environment that might crash just because we requested RW PT_GNU_STACK. (I'm ignoring existence of other libc implementations=20 here.) Best regards, Dragan