Thread (110 messages) 110 messages, 6 authors, 2024-08-21

Re: [PATCH v10 18/40] arm64/mm: Handle GCS data aborts

From: Mark Brown <broonie@kernel.org>
Date: 2024-08-19 15:14:50
Also in: kvmarm, linux-arch, linux-doc, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml

On Mon, Aug 19, 2024 at 10:17:52AM +0100, Catalin Marinas wrote:
On Thu, Aug 01, 2024 at 01:06:45PM +0100, Mark Brown wrote:
quoted
+static bool is_invalid_gcs_access(struct vm_area_struct *vma, u64 esr)
+{
quoted
+	if (unlikely(is_gcs_fault(esr))) {
+		/* GCS accesses must be performed on a GCS page */
+		if (!(vma->vm_flags & VM_SHADOW_STACK))
+			return true;
+		if (!(vma->vm_flags & VM_WRITE))
+			return true;
Do we need the VM_WRITE check here? Further down in do_page_fault(), we
already do the check as we set vm_flags = VM_WRITE.
quoted
      if (!(vma->vm_flags & vm_flags)) {
              vma_end_read(vma);
              fault = 0;
It looks bitrotted, yes.
I was wondering whether we should prevent mprotect(PROT_READ) on the GCS
page. But I guess that's fine, we'll SIGSEGV later if we get an invalid
GCS access.
Yeah, that doesn't seem like a particular problem - the concern is
adding rather than removing GCS.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help