Received-SPF: pass (google.com: domain of linux-kernel+bounces-178289-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <f1049f13-53e4-470e-89e5-d99d7e171d39@os.amperecomputing.com>
Date: Mon, 13 May 2024 21:19:39 -0600
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>
Content-Language: en-US
From: Yang Shi <yang@os.amperecomputing.com>
In-Reply-To: <Zj4O8q9-bliXE435@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?NVp4UW94RFJYSEV6TDFCRW1QOHp6ZkxxRXRsK3loNlNNRzlXVC81cFlkdjcr?=
 =?utf-8?B?anByVFZQNDN4bTZQV3NiR0hGbEwyN2I3NGRoUTdJRTZhMzZab05NakhIN3Jj?=
 =?utf-8?B?cnlNYzVSTGlFb1Q1bXpWVmN4bUMyb0EvWVpBd3ZlbVVRMkhKNzRDZExKeS9Y?=
 =?utf-8?B?RURZK1Vmdld2czhhdTBNcERRbXlhNEdlUTVaQkVqdGpQOVA2TFNCZVM0R21F?=
 =?utf-8?B?N0RQckk0cDk0N092ODd0NWdHY0JxK1FjWGNzWVUxb3NWckU4SndVWE54SXpG?=
 =?utf-8?B?bWcxa2cvdXJtWUdCcDVPdXI1SVB2dVEwbG1RY1Q2QkRHTGlyZVorZmNFQnNv?=
 =?utf-8?B?WnZDRHJ0REZpdzBVdmgrcDE5Q0ZSOW1EKzQ2eVRFMXZUODFDQzBadnc3bm1P?=
 =?utf-8?B?bTJJbldwTjVzaWhHeEg5RUtDdjIxbjZnQnJGdS9jTXpSRlhtTDd6YWVVQXF5?=
 =?utf-8?B?d2QreGxJR2Znd3VWTHFXeGx4aFptdkdrWVYzY2RNL3ZWcytRNEZPcVBwOFNR?=
 =?utf-8?B?UU5mTWVWaW9ENTdSQUQ2S1JyaTN0MGdrMy9GZjJtelZ5YnkxU3pxQ1B1ZG93?=
 =?utf-8?B?T2JqaElhMFIvb0tFNkN3aktFcTNua1ozejJrcGZnaHovMXBQa1hqSTh0N3hY?=
 =?utf-8?B?bmRvZ0FpTHd2WFNDN1BBdVpMNEJtcERZalg4MHR5RGJMM1k1ZEpxd2VRdlQ2?=
 =?utf-8?B?djNOQjZiQjhwdGlEOEpUeEovYjNSNzJrZVA4ejhhcVZpeTlTU3B2Rm15R2Iy?=
 =?utf-8?B?UmRDSHlacVVwNnY5ZFE0YWhvNit1M0k0MFJjdVlNWVBpRk9PZ0ZUSDV6S00z?=
 =?utf-8?B?NGFQdmp3eTZvMEFxQ1F6MjFHZmJyVGdXYmtpWmM1UmNIRjUzTmVsZ3BZMGJD?=
 =?utf-8?B?OWtxT21sTm5KdU5YekpjVi9lZy9URHppT3ZhYXFhejZnSit2V05YSVNUUHYv?=
 =?utf-8?B?c0RibWs5czdzT3FQbDlLS3RZdjRiRTZkZkRXRzZyUEJaZHFNR2Yyc0hreEV0?=
 =?utf-8?B?aWordThqenJTZC9jbVZObEVsUlVLeTBWdW1xUkpqQ2dsOC94RGNjeUl4ejcy?=
 =?utf-8?B?UjhGUVdUMGZTK2ZFN3BoVmJaUUo2aW85NmNoVjR0SXhHem55VUhIZ2plcWpN?=
 =?utf-8?B?SXRzVUJlcVBvVms1dDZ4VkRYWmkyem5OZ0pXa0ZXYTZLUEhRcmtjbE9PdlZY?=
 =?utf-8?B?aW1ISE05TU9uZDhWaUFXUyt5RjcwQlUrRkNwMWlTYXdxY01YbHhPSnpjVGVs?=
 =?utf-8?B?VlBvcW44ZC9pUmxJTEFzMVdscWc3aytLVjBhajgyRUFZQ21ya0Q3a0tEaTha?=
 =?utf-8?B?dFpPMEltSEttNlF5bGludGNQbDVXaUU0WC9pdWtSQUZyMFVaSm5weXk3ZnRF?=
 =?utf-8?B?ZCtkYVhHNHZndDQ0K3ErU1dkOWFyVXUyNUxKQVp3SStCUUV5SklKWkhHdXNM?=
 =?utf-8?B?SVFFQlo4MFlUbVJnODd1ZWNVUnFXNE5IOWtVdmJrUld3Tk9RTjR5eEJiRXlP?=
 =?utf-8?B?NkhYSVI1L1ZPZjJZOE13ZXVENzB6QnhhNWl2MFdsRHJNZkNmbmdVOERraFNG?=
 =?utf-8?B?MWVxcmZ0bEJEczlRbkY4NEl0SGUrcjYxUFgva1RjQmNHaDF1N2hoRU96RVFa?=
 =?utf-8?B?akRzaFB2VXE1ck5uYmRoaTFRNkZIdnhaT3RRSWhPVzhaS1BjN2Q2Zmd4YVZX?=
 =?utf-8?B?dStpaHJaeE03MDY2Wi9qYnM2ZlFPVXNZZ0dVQXBJcFlpTk13bUQ2R0lyU0hs?=
 =?utf-8?B?Y0tycVpwQlZndjNPQUl0YlE0R0JQdk96OTFtcVR2SURYcWFMSDVhRzlWSEZj?=
 =?utf-8?B?TFNOZGhZV3RrM3RKZmtJMXdXaWxPOFR6VzcwbExWVnZNMHMwSW5wK3BjOFJT?=
 =?utf-8?B?cUNJTGRMbHdSeUExM0JXVWhVZ2xPN25IeU9oK3dWalpLQWZ5TjNTUzh3OEJn?=
 =?utf-8?B?OWIyUnplS0lwbGxia3JONnYwVmNxWk15Uks0K2g5Y1A2amsxMnR5SVdBc05t?=
 =?utf-8?B?ODk1TTNzM3hPQWNBZ2R3UmtodTNybkp2NlZUd290QXhCL0R5QlM1YjcxSW9t?=
 =?utf-8?B?a3llZy83RTM1MWdhQTdIdjVwRjdOZXpDZW9hWk9tVnBWeVVrSWlja3RoZi9z?=
 =?utf-8?B?VGtldHJDbStFOUhHbjIrM2UvZm1XUXVxNEt1dzNxRXd1Z011NG5lVDJlWjFE?=
 =?utf-8?Q?F7f8Sfs/4baGGecTJdR76Cc=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32411dea-9942-4bb8-bff8-08dc73c4b302
X-MS-Exchange-CrossTenant-AuthSource: BYAPR01MB5463.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2024 03:19:43.6752
 (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: uX7BQw+HUouzabfHIHztUX/lUj7fHaFMHvekNTE88kuqHqOzF0oJ/EYQcw/nEcuOGWvdTOT/9+D1qd0EBtr2q2gY5i8sxoxdNwtzHBSHJik=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR01MB7666

>> +
>> +	if (get_user(insn, (unsigned int __user *) instruction_pointer(regs))) {
>> +		pagefault_enable();
>> +		goto continue_fault;
>> +	}
>> +
>> +	if (aarch64_insn_is_class_atomic(insn)) {
>> +		vm_flags = VM_WRITE;
>> +		mm_flags |= FAULT_FLAG_WRITE;
>> +	}
> The above would need to check if the fault is coming from a 64-bit user
> mode, otherwise the decoding wouldn't make sense:
>
> 	if (!user_mode(regs) || compat_user_mode(regs))
> 		return false;
>
> (assuming a separate function that checks the above and returns a bool;
> you'd need to re-enable the page faults)
>
> You also need to take care of endianness since the instructions are
> always little-endian. We use a similar pattern in user_insn_read():
>
> 	u32 instr;
> 	__le32 instr_le;
> 	if (get_user(instr_le, (__le32 __user *)instruction_pointer(regs)))
> 		return false;
> 	instr = le32_to_cpu(instr_le);
> 	...
>
> 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

>