From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCF7CC433E0 for ; Tue, 2 Feb 2021 08:59:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7D7F64DD6 for ; Tue, 2 Feb 2021 08:59:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232478AbhBBI7A (ORCPT ); Tue, 2 Feb 2021 03:59:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23240 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231929AbhBBI65 (ORCPT ); Tue, 2 Feb 2021 03:58:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612256250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Si/dI5lNziAyVoRmOt6q5oX+Pb8j9QNnXS8AF/vdi/A=; b=F6QniaO9pvvPoGycjt5q+69xVQC5gYdAWKcDFv7KLDsimPZOIMnlWQPQnCZkTqVc7vQR0P RHHYuN4eQ/8V7A9B/OoeSay36rT42ebxat1w0G5Tb3VzaERQTkAm8IQ4eQ3p8j2CML+qPj ry83KEIwBs0Ut82o8ypSn0J8YVarzoE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-169-sS1uv3IfMMGh_2fBHstCvQ-1; Tue, 02 Feb 2021 03:57:23 -0500 X-MC-Unique: sS1uv3IfMMGh_2fBHstCvQ-1 Received: by mail-wr1-f69.google.com with SMTP id u15so2608189wrn.3 for ; Tue, 02 Feb 2021 00:57:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Si/dI5lNziAyVoRmOt6q5oX+Pb8j9QNnXS8AF/vdi/A=; b=SgVh4+/S32v7AQB/rv/Ey/PDVFOt4qHfFNwITjmC/NjnuOxC59j/5hz89Pw5rlhG3K O9HQDldk0IT7JJfc6gy/sVsWm9z6eHuQ0tyZplvnAANw+Qe+6IOlTmVLksmreE9PPWfX Q4T63AUGX0V2/62RWc0yqkMnLRZpJJiXMJQuG7pZUn979aIzFLd1/sFQQmHD2q3GJAQR C3du6j75oeqXlqJ3pN1iJxJsv1j+TRfNPlMmLSC4JeC5o1mjmevYblmptM4hlYrQ8jiQ 6TEPw9LMbpVu5gBEZLV3i21rhtMFIxKfN7MTMuvPfVebaSP9xOCFYjwXsOURDEakLmzd gSdQ== X-Gm-Message-State: AOAM530uJvUVDl3wR9CArdmGXfLKVUUjJ4JB7X7CKNEZByERSXla5VJ+ 9PpicLag5d+3vodw3OLFGr2bpn2Aqc+fBBys/nsHjP5vJMclP17XrilAs+Z0fy3WIvv7F/QfQhu CY1xiWvfnL6h+3vXBVgE7ul5c X-Received: by 2002:a05:6000:192:: with SMTP id p18mr22178812wrx.69.1612256242134; Tue, 02 Feb 2021 00:57:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgPkiIX+L54pamL9Mka7GlGAiN10QTM7Wb7cXKG91/ROpxarDwNpZ+XfHCi6Y0Xzv6dxYUrw== X-Received: by 2002:a05:6000:192:: with SMTP id p18mr22178791wrx.69.1612256241890; Tue, 02 Feb 2021 00:57:21 -0800 (PST) Received: from ?IPv6:2a01:cb14:499:3d00:cd47:f651:9d80:157a? ([2a01:cb14:499:3d00:cd47:f651:9d80:157a]) by smtp.gmail.com with ESMTPSA id i7sm2269412wmq.2.2021.02.02.00.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Feb 2021 00:57:21 -0800 (PST) Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 To: Nick Desaulniers , Josh Poimboeuf Cc: Ard Biesheuvel , Mark Brown , Catalin Marinas , Kees Cook , Linux ARM , linux-efi , linux-hardening@vger.kernel.org, LKML , Mark Rutland , Masahiro Yamada , Michal Marek , Peter Zijlstra , raphael.gault@arm.com, Will Deacon , clang-built-linux , Bill Wendling References: <20210120173800.1660730-13-jthierry@redhat.com> <20210127221557.1119744-1-ndesaulniers@google.com> <20210127232651.rj3mo7c2oqh4ytsr@treble> <20210201214423.dhsma73k7ccscovm@treble> From: Julien Thierry Message-ID: <671f1aa9-975e-1bda-6768-259adbdc24c8@redhat.com> Date: Tue, 2 Feb 2021 09:57:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/2/21 12:17 AM, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf wrote: >> >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf wrote: >>>> >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>> From: Raphael Gault >>>>>> >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>> information in an ".discard.switch_table_info" section which will be >>>>>> used by objtool. >>>>>> >>>>>> Signed-off-by: Raphael Gault >>>>>> [J.T.: Change section name to store switch table information, >>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>> Add a relocation in the switch_table_info that points to >>>>>> the jump operation itself] >>>>>> Signed-off-by: Julien Thierry >>>>> >>>>> Rather than tightly couple this feature to a particular toolchain via >>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>> for toolchains to implement (perhaps via a -f flag). >>>> >>>> The problem is being able to detect switch statement jump table vectors. >>>> >>>> For a given indirect branch (due to a switch statement), what are all >>>> the corresponding jump targets? >>>> >>>> We would need the compiler to annotate that information somehow. >>> >>> Makes sense, the compiler should have this information. How is this >>> problem solved on x86? >> >> Thus far we've been able to successfully reverse engineer it on x86, >> though it hasn't been easy. >> >> There were some particulars for arm64 which made doing so impossible. >> (I don't remember the details.) The main issue is that the tables for arm64 have more indirection than x86. On x86, the dispatching jump instruction fetches the target address from a contiguous array of addresses based on a given offset. So the list of potential targets of the jump is neatly organized in a table (and sure, before link time these are just relocation, but still processable). On arm64 (with GCC at least), what is stored in a table is an array of candidate offsets from the jump instruction. And because arm64 is limited to 32bit instructions, the encoding often requires multiple instructions to compute the target address: ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset adr x_dest_base, // load target branch for offset 0 add x_dest, x_target_base, x_offset, ... // compute final address br x_dest // jump Where this gets trickier is that (with GCC) the offsets stored in the table might or might not be signed constants (and this can be seen in GCC intermediate representations, but I do not believe this information is output in the final object file). And on top of that, GCC might decide to use offsets that are seen as unsigned during intermediate representation as signed offset by sign extending them in the add instruction. So, to handle this we'd have to track the different operation done with the offset, from the load to the final jump, decoding the instructions and deducing the potential target instructions from the table of offsets. But that is error prone as we don't really know how many instructions can be between the ones doing the address computation, and I remember some messy case of a jump table inside a jump table where tracking the instruction touching one or the other offset would need a lot of corner case handling. And this of course is just for GCC, I haven't looked at what it all looks like on Clang's end. > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. > Sorry, I will need to make that clearer. The next patch explains it a bit [1] Basically, for simplicity, the plugin creates a new section containing tables (one per jump table) of references to the jump targets, similar to what x86 has, except that in this case this table isn't actually used by runtime code and is discarded at link time. I only chose this to minimize what needed to be changed in objtool and because the format seemed simple enough. But I'm open on some alternative, whether it's a -fjump-table-info option added to compilers with a different format to do the links. The important requirement is to be able to know all the candidate targets for a "br " instruction. [1] https://lkml.org/lkml/2021/1/20/910 Thanks, -- Julien Thierry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FCEEC433DB for ; Tue, 2 Feb 2021 08:58:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C45D164E2E for ; Tue, 2 Feb 2021 08:58:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C45D164E2E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0U5d5GRIFW264BqpG06rS3cT2ZwVyW3fqLJeH4cRBK4=; b=1IWau3E412hppwyPoSf1ja74P IrN++veULf+jMHN9/gZYEvZPHtcK47quszRB1i5hClQZOXOrulINir9Iwe0TO5rLQf/cMfV6hy6L4 5zNnZLGs1cFpFzIhuBcVQ+lLzjqEnqgVhbetvZrzchKcAoEtjvATJ8Ibrjnl0EA/EZL7l4D4gSNHF Jj4J9Zl/Iwxfiq9X3WHeizJZiYmks4/MrpdU+QpetVH/5R+EZYutcE8eHD+AXAN4HGjQv1DCIn6KN 69XZj+zv5kJlWv4Ytd+5PG2hynrHj788rFAJNzIioXlatDbHLU72VWqcCuQiDXClKdi7gBMDJ7SOH jYqd8kjjg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6rV9-0006QS-2k; Tue, 02 Feb 2021 08:57:35 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6rV6-0006Pp-96 for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 08:57:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612256251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Si/dI5lNziAyVoRmOt6q5oX+Pb8j9QNnXS8AF/vdi/A=; b=EZJRp7EQfdi46PnpA0RuvNxWGcS0iISDPJx7mBczbfJJysi5E1mXosckujW8kd0VrEIHkv KYpOs1h8pnhOciL34gDxvAOSfnYNHG1rUmvczg6yl7WTfhjiEFgNRpaGO4tlUDbnebaK/f sGJuMU9Ewh7P0QITpQ70LW7mSq4aUd4= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397--bwqTFlINYex2d3pv6APmA-1; Tue, 02 Feb 2021 03:57:23 -0500 X-MC-Unique: -bwqTFlINYex2d3pv6APmA-1 Received: by mail-wr1-f70.google.com with SMTP id x12so12216536wrw.21 for ; Tue, 02 Feb 2021 00:57:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Si/dI5lNziAyVoRmOt6q5oX+Pb8j9QNnXS8AF/vdi/A=; b=hiYWRHPibuX8Nl5pl8dMLy7ddgnlguE6VqzvK0uzK/fzC80ppg4lL5IkTXwdGfjJTb Xroj8QVWPHvxRSkjBdczZ+oS192h21HXw1smxkhywAKkDj0hdMCsWRR7eC2uL0KfwFit 6iKWwBCtI4yuM9dQElBnxdNzqMXy7b+iP/LU19lAepepnQ86Kp0v9HeNIJsxVL3+ow5V ch0kKp/zZoAUSRIpOo0HPGwyuhm8TP3GreDH3+5IMtf2aFGTe1vi9O6dWc/SsWZ5xW19 RA3nYJhxT2ASm4TPpPcMozYRn0k7Mw75UBQXcSJqU7f1UVhBaHa+aKioF/XzDRBfmP/s eb8A== X-Gm-Message-State: AOAM530704nRackloOU/fe5atNB8vJj2MuOYBiEwPVKmbouYz+n3V1eX 06RkZGQzgtSNlFQwbD2N4kaTvP8JIs625Vd6iPLQqSbS8rSAQEWwox/LRYn1HOn59Picisj18it cgFrcDHHQCMGzu0xNbIuEsjOzJf+ynzaACxY= X-Received: by 2002:a05:6000:192:: with SMTP id p18mr22178818wrx.69.1612256242135; Tue, 02 Feb 2021 00:57:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgPkiIX+L54pamL9Mka7GlGAiN10QTM7Wb7cXKG91/ROpxarDwNpZ+XfHCi6Y0Xzv6dxYUrw== X-Received: by 2002:a05:6000:192:: with SMTP id p18mr22178791wrx.69.1612256241890; Tue, 02 Feb 2021 00:57:21 -0800 (PST) Received: from ?IPv6:2a01:cb14:499:3d00:cd47:f651:9d80:157a? ([2a01:cb14:499:3d00:cd47:f651:9d80:157a]) by smtp.gmail.com with ESMTPSA id i7sm2269412wmq.2.2021.02.02.00.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Feb 2021 00:57:21 -0800 (PST) Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 To: Nick Desaulniers , Josh Poimboeuf References: <20210120173800.1660730-13-jthierry@redhat.com> <20210127221557.1119744-1-ndesaulniers@google.com> <20210127232651.rj3mo7c2oqh4ytsr@treble> <20210201214423.dhsma73k7ccscovm@treble> From: Julien Thierry Message-ID: <671f1aa9-975e-1bda-6768-259adbdc24c8@redhat.com> Date: Tue, 2 Feb 2021 09:57:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jthierry@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_035732_368383_7DCC122D X-CRM114-Status: GOOD ( 30.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-efi , Kees Cook , clang-built-linux , Peter Zijlstra , Catalin Marinas , Masahiro Yamada , LKML , Michal Marek , raphael.gault@arm.com, Mark Brown , linux-hardening@vger.kernel.org, Will Deacon , Ard Biesheuvel , Linux ARM , Bill Wendling Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/2/21 12:17 AM, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf wrote: >> >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf wrote: >>>> >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>> From: Raphael Gault >>>>>> >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>> information in an ".discard.switch_table_info" section which will be >>>>>> used by objtool. >>>>>> >>>>>> Signed-off-by: Raphael Gault >>>>>> [J.T.: Change section name to store switch table information, >>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>> Add a relocation in the switch_table_info that points to >>>>>> the jump operation itself] >>>>>> Signed-off-by: Julien Thierry >>>>> >>>>> Rather than tightly couple this feature to a particular toolchain via >>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>> for toolchains to implement (perhaps via a -f flag). >>>> >>>> The problem is being able to detect switch statement jump table vectors. >>>> >>>> For a given indirect branch (due to a switch statement), what are all >>>> the corresponding jump targets? >>>> >>>> We would need the compiler to annotate that information somehow. >>> >>> Makes sense, the compiler should have this information. How is this >>> problem solved on x86? >> >> Thus far we've been able to successfully reverse engineer it on x86, >> though it hasn't been easy. >> >> There were some particulars for arm64 which made doing so impossible. >> (I don't remember the details.) The main issue is that the tables for arm64 have more indirection than x86. On x86, the dispatching jump instruction fetches the target address from a contiguous array of addresses based on a given offset. So the list of potential targets of the jump is neatly organized in a table (and sure, before link time these are just relocation, but still processable). On arm64 (with GCC at least), what is stored in a table is an array of candidate offsets from the jump instruction. And because arm64 is limited to 32bit instructions, the encoding often requires multiple instructions to compute the target address: ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset adr x_dest_base, // load target branch for offset 0 add x_dest, x_target_base, x_offset, ... // compute final address br x_dest // jump Where this gets trickier is that (with GCC) the offsets stored in the table might or might not be signed constants (and this can be seen in GCC intermediate representations, but I do not believe this information is output in the final object file). And on top of that, GCC might decide to use offsets that are seen as unsigned during intermediate representation as signed offset by sign extending them in the add instruction. So, to handle this we'd have to track the different operation done with the offset, from the load to the final jump, decoding the instructions and deducing the potential target instructions from the table of offsets. But that is error prone as we don't really know how many instructions can be between the ones doing the address computation, and I remember some messy case of a jump table inside a jump table where tracking the instruction touching one or the other offset would need a lot of corner case handling. And this of course is just for GCC, I haven't looked at what it all looks like on Clang's end. > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. > Sorry, I will need to make that clearer. The next patch explains it a bit [1] Basically, for simplicity, the plugin creates a new section containing tables (one per jump table) of references to the jump targets, similar to what x86 has, except that in this case this table isn't actually used by runtime code and is discarded at link time. I only chose this to minimize what needed to be changed in objtool and because the format seemed simple enough. But I'm open on some alternative, whether it's a -fjump-table-info option added to compilers with a different format to do the links. The important requirement is to be able to know all the candidate targets for a "br " instruction. [1] https://lkml.org/lkml/2021/1/20/910 Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel