[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220511072651.GV76023@worktop.programming.kicks-ass.net>
Date: Wed, 11 May 2022 09:26:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"H . J . Lu" <hjl.tools@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 09/10] x86/mm: Add userspace API to enable Linear Address
Masking
On Wed, May 11, 2022 at 05:27:50AM +0300, Kirill A. Shutemov wrote:
> @@ -1013,8 +1017,23 @@ static long thread_feature_prctl(struct task_struct *task, int option,
>
> /* Handle ARCH_THREAD_FEATURE_ENABLE */
>
> + if (features & (X86_THREAD_LAM_U48 | X86_THREAD_LAM_U57)) {
> + long ret;
> +
> + /* LAM is only available in long mode */
> + if (in_32bit_syscall())
> + return -EINVAL;
So what happens if userspace sets up a 32bit code entry in the LDT and
does the LAM thing as a 64bit syscamm but then goes run 32bit code?
> +
> + ret = enable_lam(task, features);
> + if (ret)
> + return ret;
> + }
> +
> task->thread.features |= features;
> out:
> + /* Update CR3 to get LAM active */
> + switch_mm(task->mm, task->mm, task);
> +
> return task->thread.features;
> }
>
Powered by blists - more mailing lists