Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1607262ybi; Sat, 8 Jun 2019 13:56:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqxwo9n4iwqV6vOVoy11v+VKZkO6mSFsi3/w0yaSVawZoxi0hS1WHDztGMEhcw+mlgObCNWi X-Received: by 2002:a62:ed09:: with SMTP id u9mr65816329pfh.23.1560027380387; Sat, 08 Jun 2019 13:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560027380; cv=none; d=google.com; s=arc-20160816; b=TE/5scBlifrtENvENMEcbB5PBzjcR9jEbmaX6BaFPm5vFb0HR316B0k8Pl/OE5um8F +T6L/t67yAknRB8InliwgoiX4Itu/cY8K9syXI6Fb+Y7M4U+fmQXViRVTlUwX0hebTpC owp8mcaklobpUn+BXTuJk3mepDpqEETnWwRLMApC4PYkgBJxxnwiRamfUwqQFRqay/xl eeDgiXdqwPNGeCJsN3LFIEh+4wkw9C1UTAhihgzpLdHR4cmIidTqmqsIiEGDRGkUhQZA gbqItcEVLeEsCP2LPaPLUMC/kZ+lZ8xH1ptwCnhIwYnL4SEQGPl2qTlPZ3YPI9vCMUJZ znIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=RTjp2xeSAxDyXRORYBphlNukJB5yzn4j63QvdEaGPdk=; b=TMypDh4oQyEKSPOi2qiyjxAzr1FbYGAcw0LpY21mjZWrCK6JPv0z4CsLJeaRZ4HSTL XoN+2ytRyuOshNW6ocn8CASUmee0luGDeDIBBORb7x++GPDYtiQJkIDIWe93AZV3tjb7 uxJTRShZQk1RjluQu44gMXPIhvg68mffJosQbo7jPHF/EZunPGh+XvP2RmEoahXZs4Ln jcuIqTxGCRN2a2ZJk4eWMiixu2CXtBOCitSybZmfrq4fXgKVZjzQ9fykduo/5yqK1v8J /LVq8zZ2HeCO7FYYubU/qMtar0v7iTKEX4gOjuIKqD3LsefmK0MoFgFI4fhwKUr9zfzD y97A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15si5757476pgs.43.2019.06.08.13.55.53; Sat, 08 Jun 2019 13:56:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727509AbfFHUwa (ORCPT + 99 others); Sat, 8 Jun 2019 16:52:30 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:38279 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727372AbfFHUw3 (ORCPT ); Sat, 8 Jun 2019 16:52:29 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id BFAAC801E8; Sat, 8 Jun 2019 22:52:15 +0200 (CEST) Date: Sat, 8 Jun 2019 22:52:18 +0200 From: Pavel Machek To: Dave Hansen Cc: Peter Zijlstra , Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Message-ID: <20190608205218.GA2359@xo-6d-61-c0.localdomain> References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <20190606200926.4029-4-yu-cheng.yu@intel.com> <20190607080832.GT3419@hirez.programming.kicks-ass.net> <20190607174336.GM3436@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > I've no idea what the kernel should do; since you failed to answer the > > question what happens when you point this to garbage. > > > > Does it then fault or what? > > Yeah, I think you'll fault with a rather mysterious CR2 value since > you'll go look at the instruction that faulted and not see any > references to the CR2 value. > > I think this new MSR probably needs to get included in oops output when > CET is enabled. > > Why don't we require that a VMA be in place for the entire bitmap? > Don't we need a "get" prctl function too in case something like a JIT is > running and needs to find the location of this bitmap to set bits itself? > > Or, do we just go whole-hog and have the kernel manage the bitmap > itself. Our interface here could be: > > prctl(PR_MARK_CODE_AS_LEGACY, start, size); > > and then have the kernel allocate and set the bitmap for those code > locations. For the record, that sounds like a better interface than userspace knowing about the bitmap formats... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html