From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f180.google.com (mail-dy1-f180.google.com [74.125.82.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5ED6126AC3 for ; Thu, 26 Feb 2026 21:04:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772139864; cv=none; b=HKqLgKPqUJEeas6ScJ+xw2ekUj6O5GmQs0EhBTKTWOrV1ex/PasWHEimcmBc2Uvr7ibRexzUaPzc89e88xs27rYy+Y4+u+6X6TFa5hLNBncyVJMA2U2kf21ZuKBdkAykfVCbhOQxpm3XucBQ44vRDh92+UXaEriiVsxQvn6RrlU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772139864; c=relaxed/simple; bh=gpuEX6ZXECU1sTtX0OATqZTHxARQ9iBkDiSIfGmB9Qk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rFHlzMA8y20+WiURvgJcg42alvJ2k5xF8Bcwi7V7dgLDNezHA+KfRR4LT96k3YMQyc2v02yMkMeZ1/21PABCbPeRVHRnhPC14MQpt9d2GRlzsmm6hAoBGJYcvv/wk/J+XHlpk69LjztTEnn078p2gmqE+VKKv4HhTZr6OIzJQi4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b=FaVmqSOO; arc=none smtp.client-ip=74.125.82.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b="FaVmqSOO" Received: by mail-dy1-f180.google.com with SMTP id 5a478bee46e88-2bdc47747e2so1128078eec.0 for ; Thu, 26 Feb 2026 13:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc.com; s=google; t=1772139861; x=1772744661; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=BfmlzwEDHS4WYea4lib/8b6e0GAArKK1a+mu7MGsjt8=; b=FaVmqSOOYV1pVFmygYvDyqtvj8uZXs+mToTLovBCQY6BBPmJO+E36fder074yW5Bpc FJkom8xkZshRSJa/zRlRW8neeP3L6BkWnTk/nv4jcsnTQkA+k9HMyA+ppqcbHKnbAZGr EVKHMasi9WFngGhLhNqndwrD1maycIGus930qs1BtQg8twIDhPYF9FXf1qyk30S5Xs6S gozuww49/EyvpvCbbZmGxH5//nf5GRBJZSQDZLagZfF8GnYrK+gkkspePYEfvvTSkDAr ly45l8rX+NKhHwhbma/DI194vt+YeTpYpi+Mir7wF7VCYfRT8DchSNLOUFugEa42ah/f AIYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772139861; x=1772744661; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BfmlzwEDHS4WYea4lib/8b6e0GAArKK1a+mu7MGsjt8=; b=SWU2/KFzTWSKwYYapqVrfKjbZuO7NfKpHaxWtIjUMBNJGaA1XaZpRTpKxJu8BXHuWe YRE2vUVZzo3TwTSZVz3llUfouSsg9aAqWXJWhnivfAp3EPDQMy4slz3RFW/OrgSPHmqT m9/4j86Nxrk7cXj42F8eRmXWx2dzXXYez8pyGJN/Ojf8h/jM7vDJu5BHW7X385mpj7ok f7RgLxJ3Mywk6t79HqyEwAFH5l+FHBINGZz/RGQzVLSzwO3Tzplk3x1vo1/uVCeWGUjW C7luMdFsvMj5pdNWLLj6xbTeBCkUKm+YSii+hDVD8q+QglUS3KZ9eiOt73CdrTsz1O1L 6AZg== X-Forwarded-Encrypted: i=1; AJvYcCW1uJv9p31PvYw4Wo4SvtK2F5zaE0rQXjjZ1pCfLgQRURLE4CCws2zu3BPXdFjMbbbJLnyv9rwrWdD5WXM=@vger.kernel.org X-Gm-Message-State: AOJu0YycxpNVY6abP2mWkKh5Mw1cZbbu7wH/oLxrwv6pPEI65AB75eIS GdslNA+3XMx9RG7asiTWHeVp1jxB3h6dUhTZ8snhsCXlBEPBvAXyRup8aDQwIE/l1wQ= X-Gm-Gg: ATEYQzx651yyOBwXX6L5mUMdNkL4RvzYMlCBKthG5iQaiNK42VKk2SE5jchpTF0+noM KQqImcuZITSshvxkGHXQKoLE5y+sgP93Xg792iUVaWF3pZTjPxBoQFDb2Qwaa8r1gJT3Nxt4RWt ovgLY5XSmP/J0xYaFbdZ7yjkNGr2KaeKJXq2e0NkQzC3nRvqGTbqY/DjMwLqakuB2I4nIHIaoc/ VFUOMfXGbPiO0Ol3UjQJmbykLhwbj4WOLvhbBxLlxzNfaHSDTJVLVxlc1rm0ndlvbBQCP2wMlC4 STzep6MID6qyurt36ApTkM+BHuU3FhlCPxILv/LAFTr3EdXlBfB2Bn03MTQhZq0PrdDke7dxqhS u0Cr+4oh7PwvYCgIcWmZd2TwRkzcoX0qauhDHomTje+C9DV0QEzij2ZX9H8WAplgGUvxpQcHtVR ppDCTSAJLtgC9a2OSlQzX83mpsfwVEIrUF X-Received: by 2002:a05:7300:3b24:b0:2ba:6b3a:7696 with SMTP id 5a478bee46e88-2bde1b504e4mr184408eec.8.1772139861383; Thu, 26 Feb 2026 13:04:21 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bdd1bcea4esm2597709eec.5.2026.02.26.13.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 13:04:20 -0800 (PST) Date: Thu, 26 Feb 2026 13:04:19 -0800 From: Deepak Gupta To: Peter Zijlstra Cc: "Edgecombe, Rick P" , "torvalds@linux-foundation.org" , "Yu, Yu-cheng" , "linux-riscv@lists.infradead.org" , "broonie@kernel.org" , "pjw@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "zong.li@sifive.com" Subject: Re: [GIT PULL] RISC-V updates for v7.0 Message-ID: References: <2248971d-d69c-65fb-93b4-10f0d7d8bbad@kernel.org> <196537b2933567d1781901f813a72ffffedd10fd.camel@intel.com> <20260226132342.GC606826@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260226132342.GC606826@noisy.programming.kicks-ass.net> Hi Peter, Responses inline. On Thu, Feb 26, 2026 at 02:23:42PM +0100, Peter Zijlstra wrote: >On Wed, Feb 18, 2026 at 05:57:45PM -0800, Deepak Gupta wrote: > >> x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it >> does have mechanism where a bitmap has to be prepared and each entry in bitmap >> encodes whether a page is legacy code page (without `endbr64`) or a modern code >> page (with `endbr64`). And CPU will consult this bitmap to suppress the fault. > >So; all of this is only ever relevant for programs that are mixing CFI >and !CFI code. If a program has no CFI, all good. If a program is all >CFI enabled, also all good. > >If it starts mixing things, then you get to be 'creative'. > >Now the thing is, if you start to do that you need to deal with both >forward CFI (BTI) and backward CFI (shadow-stack) #CF exceptions. That >bitmap, that can only deal with BTI, but doesn't help with shadow >stack, so its useless. > >My proposal was to ignore that whole bitmap; that's dead hardware, never >used. Instead use a software PTE bit, like ARM has, and simply eat the >#CF look at PTE and figure out what to do. IIRC, arm has hardware PTE bit saying this is a guarded page. That can be kept in ITLB as part of virt addr translation during instruction fetch. So whenever indir_call --> target happens, if target translation was already in ITLB, CPU already knows whether to suppress the fault or not, without going to kernel. In x86 case, using a software PTE bit would be different. There will be a fault always and kernel won't be able to make a decision on what to do. It'll need some delegating authority to make that decision. That delegating authority can be a signal handler in userspace which may need a bitmap/auxilliary data structure of sort to make that decision whether target address is a taken target or should not be taken. So decision point is either - do a software bitmap or - hardware bitmap (legacy interworking bitmap) (both will be slow). OR Just don't allow/support that configuration to enable CFI. And put onus on workload owner to do the work to enable the feature. Sidenote: I wish we were able to convince someone certain in Redmond to give a sw bit back and this all would have been nicer. Given there wasn't a lot of traction from open source for this feature, it was mostly a redmond driven feature. > >Yes, this is 'slow', but my claim is that this doesn't matter. There are >2 ways out of this slow-ness: > > - fully disable CFI for your program (probably not the thing you want, > but a quick fix, and not really less secure than partial CFI anyway). > > - fully enable CFI for your program (might be a bit of work). > >The whole mixed thing is a transition state where userspace doesn't have >its ducks in a row. It will go away. I have spent 8 years defining features to kill class of low-level exploits back at Intel. And then next 6 years in places where software is deployed on these CPUs. I am a security engineer and would have loved to get these features enabled. But in all honesty, I am yet to see anyone at these places (hyperscalars) willing to give up an ounce of perf budget (1-2% demands discussion and strong justification) for enabling just the shadow stack feature. So my advise would be not to care about enabling path where there is a perf hit. Keep it simple - Enable when all binaries have feature awareness. - Disable when there is one binary with no feature awareness. > >