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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DD78C433EF for ; Fri, 8 Apr 2022 00:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gk2OQBcnWVPT7f0MzKaZlOGZHFUDo0NSPnOpv//Ysks=; b=QXeS+dBSzFljln tyKFaj3JvaH2KoE7hnIQg2bUOa+NMYB8q5p2qJ2HnCcGYDmukqtLeMzL5JHJAWkEWpeGc42J9BW2e R1EtIls7YGQz+YTSbuD8C2sF45YW/q2SCNgpmcRZimYpvZCzHMISVe332laK17CWZ41yEpdJEShvD xgM8A1uhQNdhtIoycQGqsM0DJNQ7Mlrn/HXarz+ParBtGifXDeTZu/PDf7ZI3eCvqHNNlwq/G7alz AbcFL2sx2+913rj6PXqRL0fKisWhcoSDZ3yBG6OlNWjpjCiFpphIMCnki6K4lzevQkTJ19U+dFoC5 0o+J/2cAOCSVglIUWa4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nccNz-00EPxV-7H; Fri, 08 Apr 2022 00:21:59 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nccNv-00EPwi-Rn for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 00:21:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649377313; 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: in-reply-to:in-reply-to:references:references; bh=ZonmDGhG6Ei2GHwUj3ZdEVwNc8Wy/16NayqTTmMzuwc=; b=WQCjTQMwoThspFlKR4ENm69GC1B5umGO/ExX0FzjpYR77LmBw2Ld3U53dUAfkvOta7cxb2 b7v4rctqZprC6Fn60ZbEzRFCNfvBB61SwaQjXanRhP25cINNkZRfYGM2tBgFbM52FDhLh1 bLsnxSC8ZK1BnbEEQ3S6tWtRRa2mYxQ= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-169-Fzz3aP9ZNw2mm9HmCjjUtw-1; Thu, 07 Apr 2022 20:21:52 -0400 X-MC-Unique: Fzz3aP9ZNw2mm9HmCjjUtw-1 Received: by mail-qv1-f70.google.com with SMTP id jq7-20020ad45fc7000000b00443f07ce3fcso8134871qvb.2 for ; Thu, 07 Apr 2022 17:21:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZonmDGhG6Ei2GHwUj3ZdEVwNc8Wy/16NayqTTmMzuwc=; b=aMNJ3+p/24CEY7CZcZG+AHrrLmE5Qtzn+aElhpkJHrCtDTqt8ptFuWvmrubt3ybxp3 bSQettIOeP3JVU1+60f+XDoxLvCHeF/6+YcMhD/642XsJXWTgfjnAHNi2S6CrN15pLRP nmBIF2SglMYJ+HL0GME+6uI0B4Pey4doSI1QO7/MdOIx8ynPX2sR/KRWjnlSRycUmnUu IxBMauORbLeG/Zyev7m70NAxKE91OjY27Xd7CCLzPxOd2enBIsQbRpZFGRZVmXkO6eWK UAQejTgTC2haoPeomYTx8C8nlQqB8S7tYb9/+4eiKHlfYxnsBurDYyI9oQQg5tUxL+p+ swmQ== X-Gm-Message-State: AOAM533vyttMglYP/XbCtozQXZmdo8Ajxlk/RSMsAMEahNKej4ueEBD4 FLy1fssvzrBxNzu4RlzBhJATHsVsEik5WmJTmZDC1s4nhvoWSXjksRKOZYeRi+jrOnQdw2ya9GF hnVAtzcDvDwVTMXI3WQSZe9N3zta0yXa3d78= X-Received: by 2002:a05:6214:2466:b0:441:2daa:4ab1 with SMTP id im6-20020a056214246600b004412daa4ab1mr14363349qvb.12.1649377311660; Thu, 07 Apr 2022 17:21:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyABym9CrcYrMyehlVw8QJv0G9OjD6XnfCJAdri20QerkAWI+6pnBBMq3wC8o95yaEireiLcA== X-Received: by 2002:a05:6214:2466:b0:441:2daa:4ab1 with SMTP id im6-20020a056214246600b004412daa4ab1mr14363333qvb.12.1649377311423; Thu, 07 Apr 2022 17:21:51 -0700 (PDT) Received: from treble ([2600:1700:6e32:6c00::15]) by smtp.gmail.com with ESMTPSA id d6-20020ac85d86000000b002e1e20444b6sm16357246qtx.57.2022.04.07.17.21.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 17:21:50 -0700 (PDT) Date: Thu, 7 Apr 2022 17:21:47 -0700 From: Josh Poimboeuf To: madvenka@linux.microsoft.com Cc: mark.rutland@arm.com, broonie@kernel.org, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 0/9] arm64: livepatch: Use DWARF Call Frame Information for frame pointer validation Message-ID: <20220408002147.pk7clzruj6sawj7z@treble> References: <95691cae4f4504f33d0fc9075541b1e7deefe96f> <20220407202518.19780-1-madvenka@linux.microsoft.com> MIME-Version: 1.0 In-Reply-To: <20220407202518.19780-1-madvenka@linux.microsoft.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jpoimboe@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_172156_013780_9BC86E1D X-CRM114-Status: GOOD ( 28.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 07, 2022 at 03:25:09PM -0500, madvenka@linux.microsoft.com wrote: > The solution > ============ > > The goal here is to use the absolute minimum CFI needed to compute the FP at > every instruction address. The unwinder can compute the FP in each frame, > compare the actual FP with the computed one and validate the actual FP. > > Objtool is enhanced to parse the CFI, extract just the rules required, > encode them in compact data structures and create special sections for > the rules. The unwinder uses the special sections to find the rules for > a given instruction address and compute the FP. > > Objtool can be invoked as follows: > > objtool dwarf generate Hi Madhaven, This is quite interesting. And it's exactly the kind of crazy idea I can appreciate ;-) Some initial thoughts: 1) I have some concerns about DWARF's reliability, especially considering a) inline asm, b) regular asm, and c) the kernel's tendency to push compilers to their limits. BUT, supplementing the frame pointer unwinding with DWARF, rather than just relying on DWARF alone, does help a LOT. I guess the hope is that cross-checking two "mostly reliable" things against each other (frame pointers and DWARF) will give a reliable result ;-) In a general sense, I've never looked at DWARF's reliability, even for just normal C code. It would be good to have some way of knowing that DWARF looks mostly sane for both GCC and Clang. For example, maybe somehow cross-checking it with objtool's knowledge. And then of course we'd have to hope that it stays bug-free in future compilers. I'd also be somewhat concerned about assembly. Since there's nothing ensuring the unwind hints are valid, and will stay valid over time, I wonder how likely it would be for that to break, and what the implications would be. Most likely I guess it would break silently, but then get caught by the frame pointer cross-checking. So a broken hint might not get noticed for a long time, but at least it (hopefully) wouldn't break reliable unwinding. Also, inline asm can sometimes do stack hacks like "push;do_something;pop" which isn't visible to the toolchain. But again, hopefully the frame pointer checking would fail and mark it unreliable. So I do have some worries about DWARF, but the fact that it's getting "fact checked" by frame pointers might be sufficient. 2) If I understand correctly, objtool is converting parts of DWARF to a new format which can then be read by the kernel. In that case, please don't call it DWARF as that will cause a lot of confusion. There are actually several similarities between your new format and ORC, which is also an objtool-created DWARF alternative. It would be interesting to see if they could be combined somehow. 3) Objtool has become an integral part of x86-64, due to security and performance features and toolchain workarounds. Not *all* of its features require the full "branch validation" which follows all code paths -- and was the hardest part to get right -- but several features *do* need that: stack validation, ORC, uaccess validation, noinstr validation. Objtool has been picking up a lot of steam (and features) lately, with more features currently in active development. And lately there have been renewed patches for porting it to powerpc and arm64 (and rumors of s390). If arm64 ever wants one of those features -- particularly a "branch validation" based feature -- I think it would make more sense to just do the stack validation in objtool, rather than the DWARF supplementation approach. Just to give an idea of what objtool already supports and how useful it has become for x86, here's an excerpt from some documentation I've been working on, since I'm in the middle of rewriting the interface to make it more modular. This is a list of all its current features: Features -------- Objtool has the following features: - Stack unwinding metadata validation -- useful for helping to ensure stack traces are reliable for live patching - ORC unwinder metadata generation -- a faster and more precise alternative to frame pointer based unwinding - Retpoline validation -- ensures that all indirect calls go through retpoline thunks, for Spectre v2 mitigations - Retpoline call site annotation -- annotates all retpoline thunk call sites, enabling the kernel to patch them inline, to prevent "thunk funneling" for both security and performance reasons - Non-instrumentation validation -- validates non-instrumentable ("noinstr") code rules, preventing unexpected instrumentation in low-level C entry code - Static call annotation -- annotates static call sites, enabling the kernel to implement inline static calls, a faster alternative to some indirect branches - Uaccess validation -- validates uaccess rules for a proper safe implementation of Supervisor Mode Access Protection (SMAP) - Straight Line Speculation validation -- validates certain SLS mitigations - Indirect Branch Tracking validation -- validates Intel CET IBT rules to ensure that all functions referenced by function pointers have corresponding ENDBR instructions - Indirect Branch Tracking annotation -- annotates unused ENDBR instruction sites, enabling the kernel to "seal" them (replace them with NOPs) to further harden IBT - Function entry annotation -- annotates function entries, enabling kernel function tracing - Other toolchain hacks which will go unmentioned at this time... -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel