From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11136 invoked by alias); 19 Jul 2013 16:34:27 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 11111 invoked by uid 89); 19 Jul 2013 16:34:27 -0000 X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_40,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO mail-ie0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Jul 2013 16:34:26 +0000 Received: by mail-ie0-f172.google.com with SMTP id 17so1589696iea.3 for ; Fri, 19 Jul 2013 09:34:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=HnhUfSoRmhWpUszraekL5tkPvK58ZG0EckxWfmTP3Pk=; b=oriJa/mTo6wsDVNQKR3AzIUHaz272gPzPiRs5soku/Atu0Cr3vsgukM6AMpPZlOeZF hC7DjHWQiAKyTs+Ccu/vZqxHCuykUHP7sV1IZ+7Z265sMZu0v2hplbEZJgsVCmEnVXEU Hz6g7Hrp1sYesML1jHTg37y8sDZeRsiBz92Xnj2ui1i7UYBV6bDDpHyGIWhv0o3PHsrG uLtYslieQQf/hx1kBy1BdfdBeQ9CswdF1vON7MF1Mbg1HB7LsqtD6sfeCIYtmcs7G5Z5 a3aTtqmRP/z6G9mDVJ6WrBhiGuBrr8dOu4GdBtbjxrHHLSF+EC0Ch+daGWup30jY1z37 0MGA== MIME-Version: 1.0 X-Received: by 10.42.226.3 with SMTP id iu3mr11020531icb.117.1374251659560; Fri, 19 Jul 2013 09:34:19 -0700 (PDT) Received: by 10.64.43.199 with HTTP; Fri, 19 Jul 2013 09:34:19 -0700 (PDT) Date: Fri, 19 Jul 2013 16:34:00 -0000 Message-ID: Subject: ARM per-thread stack protector From: Will Newton To: libc-ports@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQncemN5tscMfquHjkiF/Kb6vDvEeKYHuDvY3q1gihB41Uq6Hm8g29gw5QaX2T+xkcKu0eia X-SW-Source: 2013-07/txt/msg00026.txt.bz2 Hi all, I've been looking into implementing pre-thread stack protector canaries for ARM and I would be interested in people's opinions on whether I have understood it correctly. At the moment the global canary value is stored in __stack_chk_guard which is exported by glibc and accesses to this variable are emitted by gcc if it detects a capable glibc version at configure time. glibc with per-thread stack canary values does not export __stack_chk_guard but adds an element to the TCB to contain the per-thread value and gcc emits TP-relative accesses to load this value. Implementing the per-thread scheme would therefore seem to me to break ABI compatibility and cause problems when mixing gcc and glibc versions: Old gcc, old glibc: OK Old gcc, new glibc: __stack_chk_guard is missing, link time failure. New gcc, old glibc: stack canary value is loaded from uninitialized TCB area, security issue. New gcc, new glibc: OK. It should be possible to add support for both schemes at the same time in glibc, exporting __stack_chk_guard at the same time as supporting per-thread canary values, which would fix the "old gcc, new glibc" case. I am not sure if there is a good fix for "new gcc, old glibc", although gcc configure could be taught about glibc versions and do the right thing for each. Or is there a simpler way to handle this? Has any other architecture implemented per-thread stack protector after already supporting the simpler scheme? Thanks, -- Will Newton Toolchain Working Group, Linaro