Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp259692ybk; Sat, 9 May 2020 02:02:26 -0700 (PDT) X-Google-Smtp-Source: APiQypLtiD6GmcqkQeT0RHabCleK72Na302yhczDXBL63fIuhwc5ndSUKQAvkw3YBZojazlh1UfA X-Received: by 2002:a17:906:687:: with SMTP id u7mr4287084ejb.149.1589014946688; Sat, 09 May 2020 02:02:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589014946; cv=none; d=google.com; s=arc-20160816; b=AaNhG1zVoKcofaEr/GoM1fQ3N4vjfm6oiwGjXEX1H5jveqfFz2Ve3wHxvWHLWTXk5X RBBGMbugRVffBBdb4k0U9BjiO0U0e5fpLllKsTK+TtN/tTg2acFhe5OPuYqcnLpdYi/i HZK2Qni7taAgnWHSNWIAckIQU5FlQt4yf7I0slHoCZMSlfRCKvoIwuiALCuzjZKT5XNB wWI+0khQq3b3TMVxFXDh+U2jCmhzERiNNTwGbKtrCgULlb7WBaBKqOdswMqT82E7v9hO D18ju9BoqkoFurH9SGMYVIutGwx502Zi5y0PSiayD4EpeRTjcBXArGBYHfu6gVFwKJum tu0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=7X3HTC7K8g1WZmOtkkq/IVK7kmDqKruVFVXKBk3Gd+Y=; b=b4AW5d8MzqPq17PS/9tuhgYvdgSWbOPWrpDMqsZ5OOQvcmbg2VDuhGREkKDxt/EvOm WorSQXjxMtW7n0dbM86+kWNEivUmteEnKn07Wum6bofMAx5kN3rh4hdv4V2/7/MKhblU kAoqjjZxRomsKxWOxENK1NWpwgSLr7vfVfTxMlnhIFmSRMV4ewUjYr0zpl8NXbditDVd 066BKdBwdKc32t92s9Qt4PuBOXdVuhQ7MwBi9k28FNMe58vFZdgMXklOFtdiSuUMuAHV XezHRzihdEDPAjau2QQDq2PTCwyOrRu4LyF2kuhb32WtphJUVp5X9+QgJZrH3wVVfOXx NVRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UtVsTny7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r11si2586099eju.467.2020.05.09.02.02.02; Sat, 09 May 2020 02:02:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UtVsTny7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727787AbgEIJAX (ORCPT + 99 others); Sat, 9 May 2020 05:00:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725989AbgEIJAV (ORCPT ); Sat, 9 May 2020 05:00:21 -0400 Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19DC0C061A0C for ; Sat, 9 May 2020 02:00:21 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id n11so3710897ilj.4 for ; Sat, 09 May 2020 02:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7X3HTC7K8g1WZmOtkkq/IVK7kmDqKruVFVXKBk3Gd+Y=; b=UtVsTny7Y0l8o3huNoShEZOlm1F3D6kGgvrdni6BMrMyubTTQwJvUqZ3SO8kFH1GTI JJGokEBGdp3RE2OJtyO9XDz2fLAJP5t+FQKTayK2Sz54uD50L0BIKLjx9pKezdEewZ1P fhLzXlV5LSXjEfrIa/+FXjyWQSUOk2nXAuaoykX8EsE9/YJ65GtT2E/ygUDjq0GkuYV0 iD/4DVKD7KW0/xDibqtEt0xZlTfZyFmlL1PL/C6h6Y0Hdf2TbrfL78jm1S0ollEp8Vog 8/Vsmz9fHW2D3xmf4pQNNyfuj9hVbMCMJQgiJUk44K1GEWHb+xwnIlPzzvAsftK2LOfW +W/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7X3HTC7K8g1WZmOtkkq/IVK7kmDqKruVFVXKBk3Gd+Y=; b=WgvSVKw9QIzvXS4YlFMAH8LT51EiiJA3NQ6xrYzCBPgOKFom7DmV1BfOXivjXFo564 cLU6YQwjiqnEz6MsEApiqrw7a7pOTInS4bp7K/ZohlfA16sFgmesGQ8zS76hqsPOjC4U Ez84xG2dgDe2u02PaSUxpZTTuu+8b5D7VcmIpoCubTRrNC5BwWwXkMj7XFLF4kU/hkCM buQ+pjoa0FsxnE2djrFR4jIwhcXJU1t4ocTxuP0ziHzyHqaI46Jvirtc754G1MhefKxL GqQfozn1XNmjXpmZQ4meq/5hQWiN5xyq/movzoeEr5xbT29MlWpu006nKEdW3ioW5tfA egvA== X-Gm-Message-State: AGi0PuYaQTsEQtCyb4uKxCmt6Sw4s6wXfYnChBArGUWKiu6f1HfVX9lM 1qbPf1lRnQelrkypZB8J7p6U0cPWCRo9AtOFiVU= X-Received: by 2002:a92:5b05:: with SMTP id p5mr6658556ilb.94.1589014819746; Sat, 09 May 2020 02:00:19 -0700 (PDT) MIME-Version: 1.0 References: <20200505131602.633487962@linutronix.de> <20200505134058.272448010@linutronix.de> In-Reply-To: <20200505134058.272448010@linutronix.de> From: Lai Jiangshan Date: Sat, 9 May 2020 17:00:08 +0800 Message-ID: Subject: Re: [patch V4 part 1 02/36] x86/hw_breakpoint: Prevent data breakpoints on cpu_entry_area To: Thomas Gleixner Cc: LKML , x86@kernel.org, "Paul E. McKenney" , Andy Lutomirski , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon , "Peter Zijlstra (Intel)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 5, 2020 at 10:15 PM Thomas Gleixner wrote: > > From: Andy Lutomirski > > A data breakpoint near the top of an IST stack will cause unresoverable > recursion. A data breakpoint on the GDT, IDT, or TSS is terrifying. > Prevent either of these from happening. > > Co-developed-by: Peter Zijlstra > Signed-off-by: Andy Lutomirski > Signed-off-by: Peter Zijlstra (Intel) > Signed-off-by: Thomas Gleixner > --- > arch/x86/kernel/hw_breakpoint.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > --- a/arch/x86/kernel/hw_breakpoint.c > +++ b/arch/x86/kernel/hw_breakpoint.c > @@ -227,10 +227,35 @@ int arch_check_bp_in_kernelspace(struct > return (va >= TASK_SIZE_MAX) || ((va + len - 1) >= TASK_SIZE_MAX); > } > > +/* > + * Checks whether the range from addr to end, inclusive, overlaps the CPU > + * entry area range. > + */ > +static inline bool within_cpu_entry_area(unsigned long addr, unsigned long end) > +{ > + return end >= CPU_ENTRY_AREA_PER_CPU && > + addr < (CPU_ENTRY_AREA_PER_CPU + CPU_ENTRY_AREA_TOTAL_SIZE); > +} Hello These two lines: s/CPU_ENTRY_AREA_PER_CPU/CPU_ENTRY_AREA_BASE/g or s/CPU_ENTRY_AREA_PER_CPU/CPU_ENTRY_AREA_RO_IDT/g or otherwise the RO_IDT is not being protected. sees: #define CPU_ENTRY_AREA_PER_CPU (CPU_ENTRY_AREA_RO_IDT + PAGE_SIZE) #define CPU_ENTRY_AREA_TOTAL_SIZE (CPU_ENTRY_AREA_ARRAY_SIZE + PAGE_SIZE) ^ sizeof PER_CPU ^ RO_IDT Reviewed-by: Lai Jiangshan > + > static int arch_build_bp_info(struct perf_event *bp, > const struct perf_event_attr *attr, > struct arch_hw_breakpoint *hw) > { > + unsigned long bp_end; > + > + bp_end = attr->bp_addr + attr->bp_len - 1; > + if (bp_end < attr->bp_addr) > + return -EINVAL; > + > + /* > + * Prevent any breakpoint of any type that overlaps the > + * cpu_entry_area. This protects the IST stacks and also > + * reduces the chance that we ever find out what happens if > + * there's a data breakpoint on the GDT, IDT, or TSS. > + */ > + if (within_cpu_entry_area(attr->bp_addr, bp_end)) > + return -EINVAL; > + > hw->address = attr->bp_addr; > hw->mask = 0; > >