[PATCH v10 18/40] arm64/mm: Handle GCS data aborts
Mark Brown
broonie at kernel.org
Mon Aug 19 08:14:41 PDT 2024
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:
> > +static bool is_invalid_gcs_access(struct vm_area_struct *vma, u64 esr)
> > +{
> > + 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.
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20240819/d81807db/attachment.sig>
More information about the linux-riscv
mailing list