From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752110AbcFFB7i (ORCPT ); Sun, 5 Jun 2016 21:59:38 -0400 Received: from mga14.intel.com ([192.55.52.115]:51174 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751806AbcFFB7h (ORCPT ); Sun, 5 Jun 2016 21:59:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,424,1459839600"; d="scan'208";a="714430525" Date: Sun, 5 Jun 2016 18:59:35 -0700 From: Andi Kleen To: Stephane Eranian Cc: David Carrillo-Cisneros , LKML , "x86@kernel.org" , Ingo Molnar , "Yan, Zheng" , Kan Liang , Peter Zijlstra Subject: Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation Message-ID: <20160606015935.GA9646@tassilo.jf.intel.com> References: <1464835323-33872-1-git-send-email-davidcc@google.com> <1464835323-33872-2-git-send-email-davidcc@google.com> <20160602160428.GR22049@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > It is not because you force LBR to ring3 only that you do not capture > kernel addresses in the FROM field. > Keep in mind that LBR priv level filtering applies to the target of > the branch and not the source. You might > still get a kernel address if returning from kernel. Now, in callstack > mode, I think the return branch is never > actually recorded in the LBR, it just causes a pop, so theoretically > this should not happen. I'd like to be > 100% sure of that, though. Far branches shouldn't be included in call stack LBR. Don't think there is any other situation where the ring 0 address could leak either. -Andi -- ak@linux.intel.com -- Speaking for myself only