Received-SPF: pass (google.com: domain of linux-kernel+bounces-182335-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <dfc3f15d-e992-46a5-8b54-185f05ff6af1@os.amperecomputing.com>
Date: Fri, 17 May 2024 09:10:40 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: mm: force write fault for atomic RMW instructions
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: will@kernel.org, scott@os.amperecomputing.com, cl@gentwo.org,
 linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
References: <20240507223558.3039562-1-yang@os.amperecomputing.com>
 <Zj4O8q9-bliXE435@arm.com>
 <f1049f13-53e4-470e-89e5-d99d7e171d39@os.amperecomputing.com>
 <ZkNCsT0dGwOyap7M@arm.com>
Content-Language: en-US
From: Yang Shi <yang@os.amperecomputing.com>
In-Reply-To: <ZkNCsT0dGwOyap7M@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Vkh1THZkOEVhNG5UOWRHUjZIeng5NElDQTRobTd2UVRwZzM0amVVTFFZZmly?=
 =?utf-8?B?VDUvYzU2R0d4c2luYUZMQ2lxTDFlRytnTkFaY2hBU2hQeDFNTWNycllpSXhl?=
 =?utf-8?B?TVpiT0t1NWQvcW1XMEZxYS94c1FVTDVjaEt6MmRJSWlDbFBxbUYvVlNmZGhE?=
 =?utf-8?B?TDVFVUFicEtIRyszZ0tGdS9kSnZ0VW9UbDVHeVZmRysyNmJqc015TXVBRWta?=
 =?utf-8?B?SldQNkNtWG0wSlFFSk1JWVBxLy9aQU5tZURweDZwS0E0Ymlzck9xK1JxWG9v?=
 =?utf-8?B?bFlrRkhCcFAyMzVvTExaSHlxMloxcHY1VURYb1ZzclQ3WG93MEw5WE9ES0VN?=
 =?utf-8?B?LzFKeGEwcGxEMzhYcUU1VXB1cEhEUkFLQU1DVDB5eXZPbEl4V2wyblRiUUlI?=
 =?utf-8?B?Q0NVMnFXSy94MzcvNUsrQXZybldsc1JkV0p1Y0thcVJSR1ppWHp2a3RMaitr?=
 =?utf-8?B?Qk9uais5V3hCeDlYVHNyclRSMUVteTBRMCt6VmdoelVCa1haSDdYN3gyVDZv?=
 =?utf-8?B?U1A2ZG1zT3ZHbW9kbGpsMmdpQ0liV0FQQWFDeURWbjBrNEw2TDBpWUw0eWxX?=
 =?utf-8?B?ZThhdHYxWGdwVmY3VDE1aVJQL2dlWUI0S2NIVFVyeVdSdjVZc0JtWm1SVmZi?=
 =?utf-8?B?b045NENZZWUwMjFhSVprY0hLaGYxZU1xY0V2OXM0emFBNTZRVVYraENwUkxB?=
 =?utf-8?B?MjRrTFZ1dXlPcHVLR0FMMXJNZjJ5dG5LMUxxR2QycE5ESTQzd3NibzdqVHhm?=
 =?utf-8?B?V2lHQXJUVkJPeVdobjA1ZUhoMFVMN0xXeTJLaDlWMXZjbmI0eFgzOFhZaE1M?=
 =?utf-8?B?Q3lCRnN3ZXZZV0cwdWRGS0Y1Mi9ndmtBeUdBNWtVRjFCbFRoOE1vY0pwcFE0?=
 =?utf-8?B?UGljRFArYUt2RW05UHdZMEVCcTdrOFpwaE11Sk9NQU9VbVpGNmRXYmpmdytP?=
 =?utf-8?B?d280RmFJZ21ENXp6blhKdW9hZ2d6ZDVaSmx1QVpEaHd0VGdlOFA3RVNOeTQ0?=
 =?utf-8?B?LzE5bFhVeUZKbTFQTTlWbUVJNTRiMHdlYUt6bUNaOWxRT2hUaFV1OXc1VVhX?=
 =?utf-8?B?ZHh3a1VkbHB2VVJndlZIZHlmZVhlcjI3NFdqK0ZXZTVNQXZ2c2Z0aWFXQjYv?=
 =?utf-8?B?eDFkRXdzcWVhVllhalBpZnNoTS9ZREszZmt3bXM0VHYrZlQ4SDh3OEpuZUZT?=
 =?utf-8?B?ZUFsdXJvbW9ad0RaNDJENklvVUFnQWs0SDR1WUxreGpERFRLdjlVdXNtSFJi?=
 =?utf-8?B?Q1Uya0d2R2xBQWFEaW9yZXZ2bXY1TzQyYU1IanVBZUE3SmN4dGtIc05hQ3Qx?=
 =?utf-8?B?WXNZalNIUERSVk9CV1RyNHpQcUlFQXRneW9Jb0VOMnA4dTJtdmtYUi9aMzVD?=
 =?utf-8?B?d1M3amg2a3kyVTlITzU5OHJtSGJkUHBGeUcxcjVVZGRGUEZrbW56UHVsblY5?=
 =?utf-8?B?NmVuanREOU8vNjJ4amM0SFpPQTh4a0phM0owTlRkZkQ2aEppUDkrWE5QYzJv?=
 =?utf-8?B?VllRY2p2SHltMHNhMzVIaFc0aVhRNU5TcjNoYzI1ZFpIVFJZVEJkM2ZuTWMw?=
 =?utf-8?B?QkV0QlM4dWdUdmFIdVlkVjUwWmVVZ09oVkxWeEwzNWUxTE4zTW9iWTJCM29M?=
 =?utf-8?B?b1ExWTlNbzdiTEtJYTdlUC9YV3diR1BtR04xS3hKcmhPL1E2eU5LdHI4SERp?=
 =?utf-8?B?OTNnM09lQU1LRGlWMDEwTDRwZi9YdFVTWGh3M3JGdkM1UkFqTVdXTGVqaDZ6?=
 =?utf-8?B?U3I2UC9temFCQkFad2lhVTZjWEtWbHYvaURmT01neTdTZ2RkQmllSVh4aUxJ?=
 =?utf-8?B?M1ZaSlhSeENoVWJtT3luL3VmZ3ZDSEJoTlNhVi9WWkJEQ1pRZ0x0cW9yK1Qw?=
 =?utf-8?B?MzdKUXdHcVI2ekVLM1BVK1FqeVRpYU93ZnNxYmNRais4UWJ1bFNDZk8wRUJ4?=
 =?utf-8?B?WEc0MjFZMWZRM0lkT0xrLzhISVJ4V1pmUSszcWIzdWo3VDlEYU45OXZhbmdw?=
 =?utf-8?B?ZzVzOGRnc0dINDY2OWpBODNSYU5KR01qRUlJb0xSdGVHeDQvS2IrY2FMRS81?=
 =?utf-8?B?VHQ4RHpENmVXVFRGOVhIRkxqTUNpUWVtZXR5c1hCRWU5OFB2UmZPNjJZaERH?=
 =?utf-8?B?bTBIUTA3dkIzWXJ0ZzRONmQyRnhTZHJnQ3ZDU3cyZ04zVUJsY0JRV3pVbEU0?=
 =?utf-8?Q?RyzgiisYONUjPwcQhp4HpXQ=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1657c02-d61a-4b8e-45af-08dc768be864
X-MS-Exchange-CrossTenant-AuthSource: BYAPR01MB5463.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2024 16:10:45.4286
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: G8xH6v6YKoQ9JOSe1pbVekRcTJB0jtd0FAcCk4jvR3o7Yl+mW2Gj6E7ipjdqvN/xSUOwvjgjqPVh5AonkIUav1Fwa+8FZhTj0hvOzxIl1xI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR01MB6683


On 5/14/24 3:53 AM, Catalin Marinas wrote:
> On Mon, May 13, 2024 at 09:19:39PM -0600, Yang Shi wrote:
>>> That said, I'm not keen on this kernel workaround. If openjdk decides to
>>> improve some security and goes for PROT_EXEC-only mappings of its text
>>> sections, the above trick will no longer work.
>> I noticed futex does replace insns. IIUC, the below sequence should
>> can do the trick for exec-only, right?
>>
>> disable privileged
>> read insn with ldxr
>> enable privileged
> Do you mean not using the unprivileged LDTR as in get_user()? You don't
> even need an LDXR, just plain LDR but with the extable entry etc.
>
> However, with PIE we got proper execute-only permission (not the kind of
> fake one where we disabled the PTE_USER bit while keeping PTE_UXN as 0).
> So the futex-style approach won't work unless we changed the PIE_E1
> entry for _PAGE_EXECONLY to be PIE_R by the kernel.

I see. Thanks. Yes, I did see this works without PIE. As you said in the 
earlier email, exec-only is not that popular yet. I think we can just 
ignore it for now.

>