On 11/12/21 16:50, Ira Weiny wrote:
On Tue, Aug 03, 2021 at 09:32:21PM -0700, 'Ira Weiny' wrote:
From: Ira Weiny
The PKRS MSR is not managed by XSAVE. It is preserved through a context
switch but this support leaves exception handling code open to memory
accesses during exceptions.
2
> On Apr 19, 2021, at 11:33 AM, Dave Hansen wrote:
>
> On 4/19/21 11:10 AM, Andy Lutomirski wrote:
>> I’m confused by this scenario. This should only affect physical pages
>> that are in the 2M area that contains guest memory. But, if we have a
>> 2M direct map PMD
> On Apr 19, 2021, at 10:58 AM, Dave Hansen wrote:
>
> On 4/19/21 10:46 AM, Brijesh Singh wrote:
>> - guest wants to make gpa 0x1000 as a shared page. To support this, we
>> need to psmash the large RMP entry into 512 4K entries. The psmash
>> instruction breaks the large RMP entry into 512
> On Apr 19, 2021, at 8:26 AM, David Laight wrote:
>
> From: Andy Lutomirski
>> Sent: 18 April 2021 01:12
> ..
>> Slightly more complicated:
>>
>> struct opaque_symbol;
>> extern struct opaque_symbol entry_SYSCALL_64;
>>
>> The op
On Sun, Apr 18, 2021 at 9:17 AM Thomas Gleixner wrote:
>
> On Sat, Apr 17 2021 at 17:11, Andy Lutomirski wrote:
> > On Sat, Apr 17, 2021 at 4:53 PM Thomas Gleixner wrote:
> >> which works for
> >>
> >> foo = function_nocfi(bar);
> >
> >
On Sat, Apr 17, 2021 at 4:53 PM Thomas Gleixner wrote:
>
> On Sat, Apr 17 2021 at 16:19, Andy Lutomirski wrote:
> > On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote:
> >> Okay, you're saying you want __builtin_gimme_body_p() to be a constant
> >> expression fo
On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote:
>
> > 1. I defined a function in asm. I want to tell clang that this
> > function is defined in asm, and for clang to behave accordingly:
> >
> > .globl func
> > func:
> > ; do stuff
> >
> > later:
> >
> > extern void func(void) [something
> On Apr 17, 2021, at 7:20 AM, David Laight wrote:
>
> From: Kees Cook
>> Sent: 16 April 2021 23:28
>>
>>> On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
>>> On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
>>>>
On Fri, Apr 16, 2021 at 3:28 PM Kees Cook wrote:
>
> On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
> > >
> > > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
> > &g
On Fri, Apr 16, 2021 at 3:14 PM Borislav Petkov wrote:
>
> On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
> > >
> > > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
>
On Fri, Apr 16, 2021 at 3:11 PM Len Brown wrote:
>
> > I get it. That does not explain why LDMXCSR and VLDMXCSR cause
> > pipelines stalls.
>
> Sorry, I thought this thread was about AMX.
> I don't know the answer to your LDMXCSR and VLDMXCSR question.
My point is that every single major math
On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
>
> On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
> > __nocfi only disables CFI checking in a function, the compiler still
> > changes function addresses to point to the CFI jump table, which is
> > why we need
On Fri, Apr 16, 2021 at 2:54 PM Len Brown wrote:
>
> On Thu, Apr 15, 2021 at 12:24 PM Andy Lutomirski wrote:
> > On Wed, Apr 14, 2021 at 2:48 PM Len Brown wrote:
>
> > > > ... the transition penalty into and out of AMX code
>
> The concept of 'transition' exists
> On Apr 15, 2021, at 10:00 AM, Dave Hansen wrote:
>
> On 4/15/21 9:24 AM, Andy Lutomirski wrote:
>> In the patches, *as submitted*, if you trip the XFD #NM *once* and you
>> are the only thread on the system to do so, you will eat the cost of a
>> WRMSR on ever
On Wed, Apr 14, 2021 at 2:48 PM Len Brown wrote:
>
>
> > Then I take the transition penalty into and out of AMX code (I'll
> > believe there is no penalty when I see it -- we've had a penalty with
> > VEX and with AVX-512) and my program runs *slower*.
>
> If you have a clear definition of what
On Tue, Apr 13, 2021 at 12:05 PM wrote:
>
> From: Kan Liang
>
> The counter value of a perf task may leak to another RDPMC task.
> For example, a perf stat task as below is running on CPU 0.
>
> perf stat -e 'branches,cycles' -- taskset -c 0 ./workload
I assume this doesn't fix the leak if
On Tue, Apr 13, 2021 at 3:47 PM Len Brown wrote:
>
> On Tue, Apr 13, 2021 at 4:16 PM Andy Lutomirski wrote:
> >
> > On Mon, Apr 12, 2021 at 4:46 PM Len Brown wrote:
> > >
> > > On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote:
> > >
> &g
On Mon, Apr 12, 2021 at 4:46 PM Len Brown wrote:
>
> On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote:
>
> > AMX: Multiplying a 4x4 matrix probably looks *great* in a
> > microbenchmark. Do it once and you permanently allocate 8kB (is that
> > even a constant?
On Mon, Apr 12, 2021 at 2:52 AM Baoquan He wrote:
>
> On 04/11/21 at 06:49pm, Andy Lutomirski wrote:
> >
> >
> > > On Apr 11, 2021, at 6:14 PM, Baoquan He wrote:
> > >
> > > On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
> > >> Why don't
On Mon, Apr 12, 2021 at 7:19 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> Maybe we could have done this in 2016 when I reported this for the first
> time. Now it is too late, as more and more software is using
> CPUID-based detection for AVX-512. Our users have
> On Apr 12, 2021, at 7:38 AM, Florian Weimer wrote:
>
> * Borislav Petkov:
>
>>> On Mon, Apr 12, 2021 at 04:19:29PM +0200, Florian Weimer wrote:
>>> Maybe we could have done this in 2016 when I reported this for the first
>>> time. Now it is too late, as more and more software is using
> On Apr 11, 2021, at 6:14 PM, Baoquan He wrote:
>
> On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
>> Why don't we do this unconditionally? At the very best we gain half a
>> megabyte of memory (except the trampoline, which has to live there, but it
>> is only a few kilobytes.)
>
> This
On Sun, Apr 11, 2021 at 10:04 AM Borislav Petkov wrote:
>
> On Sun, Apr 11, 2021 at 09:57:20AM -0700, Andy Lutomirski wrote:
> > Working around a kernel bug. The workaround only worked on AMD
> > systems. The correct solution was to fix the kernel bug, not poke
> > MSRs.
&
> On Apr 11, 2021, at 9:43 AM, Andi Kleen wrote:
>
>
>>
>> I have actually seen real user programs poke MSR_SYSCALL_MASK.
>
> Hmm, what was the use case?
>
>
Working around a kernel bug. The workaround only worked on AMD systems. The
correct solution was to fix the kernel bug, not
On Sat, Apr 10, 2021 at 11:52 AM Andi Kleen wrote:
>
> Borislav Petkov writes:
>
> > From: Borislav Petkov
> > Date: Sat, 10 Apr 2021 14:08:13 +0200
> >
> > There are a bunch of MSRs which luserspace has no business poking at,
> > whatsoever. Add a ban list and put the TSC-related MSRs in
> On Apr 10, 2021, at 5:11 AM, Borislav Petkov wrote:
>
> From: Borislav Petkov
> Date: Sat, 10 Apr 2021 14:08:13 +0200
>
> There are a bunch of MSRs which luserspace has no business poking at,
> whatsoever. Add a ban list and put the TSC-related MSRs in there. Issue
> a big juicy splat to
On Fri, Apr 9, 2021 at 1:53 PM Len Brown wrote:
>
> On Wed, Mar 31, 2021 at 6:45 PM Andy Lutomirski wrote:
> >
> > On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote:
> >
> > > We added compiler annotation for user-level interrupt handlers.
> > > I'm n
On 4/6/21 6:44 PM, Michel Lespinasse wrote:
> The page table tree is walked with local irqs disabled, which prevents
> page table reclamation (similarly to what fast GUP does). The logic is
> otherwise similar to the non-speculative path, but with additional
> restrictions: in the speculative
On Thu, Apr 1, 2021 at 3:11 PM Yu-cheng Yu wrote:
>
> When shadow stack is enabled, a task's shadow stack states must be saved
> along with the signal context and later restored in sigreturn. However,
> currently there is no systematic facility for extending a signal context.
>
> Introduce a
On Thu, Apr 1, 2021 at 3:12 PM Yu-cheng Yu wrote:
>
> A shadow stack restore token marks a restore point of the shadow stack, and
> the address in a token must point directly above the token, which is within
> the same shadow stack. This is distinctively different from other pointers
> on the
On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote:
>
> On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski wrote:
>
> > But this whole annotation thing will require serious compiler support.
> > We already have problems with compilers inlining functions and getting
> >
> On Mar 31, 2021, at 9:31 AM, Len Brown wrote:
>
> On Tue, Mar 30, 2021 at 6:01 PM David Laight wrote:
>
>>> Can we leave it in live registers? That would be the speed-of-light
>>> signal handler approach. But we'd need to teach the signal handler to
>>> not clobber it. Perhaps that
> On Mar 30, 2021, at 12:12 PM, Dave Hansen wrote:
>
> On 3/30/21 10:56 AM, Len Brown wrote:
>> On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski wrote:
>>>> On Mar 30, 2021, at 10:01 AM, Len Brown wrote:
>>>> Is it required (by the "ABI") tha
> On Mar 30, 2021, at 10:01 AM, Len Brown wrote:
>
> Andy,
>
> I agree, completely, with your description of the challenge,
> thank you for focusing the discussion on that problem statement.
>
> Question:
>
> Is it required (by the "ABI") that a user program has everything
> on the stack
> On Mar 30, 2021, at 8:14 AM, Sean Christopherson wrote:
>
> On Mon, Mar 29, 2021, Andy Lutomirski wrote:
>>
>>>> On Mar 29, 2021, at 7:04 PM, Andi Kleen wrote:
>>>
>>>
>>>>
>>>>> No, if these instructions take
On Mon, Mar 29, 2021 at 3:38 PM Len Brown wrote:
>
> On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski wrote:
> >
> Hi Andy,
>
> Can you provide a concise definition of the exact problemI(s) this thread
> is attempting to address?
The AVX-512 state, all by itself,
> On Mar 29, 2021, at 7:04 PM, Andi Kleen wrote:
>
>
>>
>>> No, if these instructions take a #VE then they were executed at CPL=0.
>>> MONITOR
>>> and MWAIT will #UD without VM-Exit->#VE. Same for WBINVD, s/#UD/#GP.
>>
>> Dare I ask about XSETBV?
>
> XGETBV does not cause a #VE, it
On Mon, Mar 29, 2021 at 4:42 PM Sean Christopherson wrote:
>
> On Mon, Mar 29, 2021, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 3/29/21 4:23 PM, Andy Lutomirski wrote:
> > >
> > > > On Mar 29, 2021, at 4:17 PM, Kuppuswamy Sathyanarayanan
>
> On Mar 29, 2021, at 2:55 PM, Marco Elver wrote:
>
> On Mon, 29 Mar 2021 at 23:47, Andy Lutomirski wrote:
>>
>>
>>>> On Mar 29, 2021, at 2:34 PM, Marco Elver wrote:
>>>
>>> On Mon, 29 Mar 2021 at 23:03, Dave Hansen wrote:
>>>
> On Mar 29, 2021, at 4:17 PM, Kuppuswamy Sathyanarayanan
> wrote:
>
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions
> appropriately.
Is there something I missed elsewhere in the code that checks CPL?
> On Mar 29, 2021, at 2:34 PM, Marco Elver wrote:
>
> On Mon, 29 Mar 2021 at 23:03, Dave Hansen wrote:
>>> On 3/29/21 10:45 AM, Marco Elver wrote:
On Mon, 29 Mar 2021 at 19:32, Dave Hansen wrote:
>>> Doing it to all CPUs is too expensive, and we can tolerate this being
>>> approximate
> On Mar 29, 2021, at 8:47 AM, Len Brown wrote:
>
> On Sat, Mar 27, 2021 at 5:58 AM Greg KH wrote:
>>> On Fri, Mar 26, 2021 at 11:39:18PM -0400, Len Brown wrote:
>>> Hi Andy,
>>> Say a mainline links with a math library that uses AMX without the
>>> knowledge of the mainline.
>
> sorry for
> On Mar 29, 2021, at 9:39 AM, Len Brown wrote:
>
>
>>
>> In particular, the library may use instructions that main() doesn't know
>> exist.
>
> And so I'll ask my question another way.
>
> How is it okay to change the value of XCR0 during the run time of a program?
>
> I submit that
> On Mar 29, 2021, at 9:06 AM, Len Brown wrote:
>
> On Mon, Mar 29, 2021 at 11:43 AM Len Brown wrote:
>>
>> On Mon, Mar 29, 2021 at 9:33 AM Thomas Gleixner wrote:
>>
I found the author of this passage, and he agreed to revise it to say this
was targeted primarily at VMMs.
>>>
> On Mar 26, 2021, at 8:40 PM, Kuppuswamy, Sathyanarayanan
> wrote:
>
>
>
> On 3/26/21 7:40 PM, Andy Lutomirski wrote:
>>>> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan
>>>> wrote:
>>>
>>> In non
> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan
> wrote:
>
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions as no ops.
These should at least be WARN.
Does TDX send #UD if these instructions have the
Sigh, cc linux-api, not linux-abi.
On Fri, Mar 26, 2021 at 4:12 PM Andy Lutomirski wrote:
>
> Hi all-
>
> After some discussion on IRC, I have a proposal for a Linux ABI for
> using Intel AMX and other similar features. It works like this:
>
> First, we make XCR0 dynamic.
Hi all-
After some discussion on IRC, I have a proposal for a Linux ABI for
using Intel AMX and other similar features. It works like this:
First, we make XCR0 dynamic. This looks a lot like Keno's patch but
with a different API, outlined below. Different tasks can have
different XCR0 values.
> On Mar 26, 2021, at 2:11 PM, Florian Weimer wrote:
>
> * Andy Lutomirski:
>
>>> On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer wrote:
>>>
>>> I mean the immense slowdown you get if you use %xmm registers after
> their %ymm counterparts (doesn'
On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote:
> >> x86: Sporadic failures in tst-cpu-features-cpuinfo
> >> <https://sourceware.org/bugzilla/show_bug.cgi?id
On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> >> > AVX-512 cleared, and programs need to explicitly request enablement.
> >> > This would allow programs to opt into not saving/restoring across
> >> > signal
On Fri, Mar 26, 2021 at 3:08 AM Borislav Petkov wrote:
>
> On Thu, Mar 25, 2021 at 09:38:24PM -0700, Andy Lutomirski wrote:
> > I think we should seriously consider solutions in which, for new
> > tasks, XCR0 has new giant features (e.g. AMX) and possibly even
> > AVX-5
On Fri, Mar 26, 2021 at 5:12 AM Florian Weimer wrote:
>
> * Andy Lutomirski-alpha:
>
> > glibc appears to use AVX512F for memcpy by default. (Unless
> > Prefer_ERMS is default-on, but I genuinely can't tell if this is the
> > case. I did some searching.) The commit
On Fri, Mar 26, 2021 at 10:54 AM Len Brown wrote:
>
> On Fri, Mar 26, 2021 at 11:48 AM Andy Lutomirski wrote:
>
> > > I submit, that after the generic XFD support is in place,
> > > there is exactly 1 bit that needs to be flipped to enable
> > > u
On Fri, Mar 26, 2021 at 8:34 AM Len Brown wrote:
>
> On Thu, Mar 25, 2021 at 9:42 PM Andy Lutomirski wrote:
>
> > Regardless of what you call AMX, AMX requires kernel enabling.
>
> I submit, that after the generic XFD support is in place,
> there is exactly 1 bit
I forgot to mention why I cc'd all you fine Xen folk:
On Thu, Mar 25, 2021 at 11:13 AM Andy Lutomirski wrote:
>
> > } else if (IS_ENABLED(CONFIG_X86_32) &&
> >!onsigstack &&
> >regs->ss != __USER_DS &&am
On Thu, Mar 25, 2021 at 11:54 AM Borislav Petkov wrote:
>
> On Thu, Mar 25, 2021 at 11:13:12AM -0700, Andy Lutomirski wrote:
> > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> > index ea794a083c44..53781324a2d3 100644
> > --- a/arch/x86/kernel/sig
Hi all-
glibc appears to use AVX512F for memcpy by default. (Unless
Prefer_ERMS is default-on, but I genuinely can't tell if this is the
case. I did some searching.) The commit adding it refers to a 2016
email saying that it's 30% on KNL. Unfortunately, AVX-512 is now
available in normal
On Thu, Mar 25, 2021 at 3:59 PM Len Brown wrote:
>
> On Sat, Mar 20, 2021 at 4:57 PM Thomas Gleixner wrote:
>
> > We won't enable features which are unknown ever. Keep that presilicon
> > test gunk where it belongs: In the Intel poison cabinet along with the
> > rest of the code which nobody
On Mon, Mar 15, 2021 at 11:57 PM Chang S. Bae wrote:
>
> The kernel pushes context on to the userspace stack to prepare for the
> user's signal handler. When the user has supplied an alternate signal
> stack, via sigaltstack(2), it is easy for the kernel to verify that the
> stack size is
> On Mar 24, 2021, at 2:58 PM, Dave Hansen wrote:
>
> On 3/24/21 2:42 PM, Andy Lutomirski wrote:
>>>>> 3. user space always uses fully uncompacted XSAVE buffers.
>>>>>
>>>> There is no reason we have to do this for new states. Arguably we
&
> On Mar 24, 2021, at 2:30 PM, Dave Hansen wrote:
>
> On 3/24/21 2:26 PM, Andy Lutomirski wrote:
>>> 3. user space always uses fully uncompacted XSAVE buffers.
>>>
>> There is no reason we have to do this for new states. Arguably we
>> shouldn’
> On Mar 24, 2021, at 2:09 PM, Len Brown wrote:
>
> On Tue, Mar 23, 2021 at 11:15 PM Liu, Jing2
> wrote:
>
>>> IMO, the problem with AVX512 state
>>> is that we guaranteed it will be zero for XINUSE=0.
>>> That means we have to write 0's on saves.
>
>> why "we have to write 0's on
On Wed, Mar 24, 2021 at 10:39 AM Vasily Gorbik wrote:
>
> Hi Andy,
>
> On Sat, Mar 20, 2021 at 08:48:34PM -0700, Andy Lutomirski wrote:
> > Hi all-
> >
> > I'm working on my kentry patchset, and I encountered:
> >
> > commit 56e62a73702836017564eaac
On Wed, Mar 24, 2021 at 10:04 AM Brijesh Singh wrote:
>
> If hardware detects an RMP violation, it will raise a page-fault exception
> with the RMP bit set. To help the debug, dump the RMP entry of the faulting
> address.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc:
Hi all-
I'm working on my kentry patchset, and I encountered:
commit 56e62a73702836017564eaacd5212e4d0fa1c01d
Author: Sven Schnelle
Date: Sat Nov 21 11:14:56 2020 +0100
s390: convert to generic entry
As part of this work, I was cleaning up the generic syscall helpers,
and I encountered
On Sat, Mar 20, 2021 at 3:13 PM Thomas Gleixner wrote:
>
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> > +
> > +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
> > +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
> > +{
> > + if
> On Mar 20, 2021, at 9:31 AM, Alexey Dobriyan wrote:
>
> PF_KTHREAD value is visible via field number 9 of /proc/*/stat
>
>$ sudo cat /proc/2/stat
>2 (kthreadd) S 0 0 0 0 -1 2129984 0 ...
> ^^^
>
> It is used by at least systemd to check for kernel-threadness:
>
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: f706bb59204ba1c47e896b456c97977fc97b7964
Gitweb:
https://git.kernel.org/tip/f706bb59204ba1c47e896b456c97977fc97b7964
Author:Andy Lutomirski
AuthorDate:Thu, 04 Mar 2021 09:01:55 -08:00
If arch code calls the wrong kernel entry helpers, syscall entries and
exits can get out of sync. Add a new field to task_struct to track the
syscall state and validate that it transitions correctly.
Signed-off-by: Andy Lutomirski
---
include/linux/sched.h | 4
init/init_task.c | 8
-by: Andy Lutomirski
---
arch/x86/kernel/traps.c | 4 ++--
include/asm-generic/bug.h | 8
include/linux/instrumentation.h | 25 -
kernel/entry/common.c | 7 +++
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel
It's quite easy to mess up kentry calls. Add debgging checks that kentry
transitions to and from user mode match up and that kentry_nmi_enter() and
kentry_nmi_exit() match up.
Checking full matching of kentry_enter() with kentry_exit() needs
per-task state.
Signed-off-by: Andy Lutomirski
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 57 +++-
include/linux/entry-common.h | 86 ++--
kernel/entry/common.c| 57 +++-
3 files changed, 54 insertions(+), 146 deletions(-)
diff --git
. If an architecture wants to use
DEBUG_ENTRY without using GENERIC_ENTRY, this could be changed.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig.debug | 10 --
lib/Kconfig.debug | 11 +++
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/Kconfig.debug b/arch
isn't built on arm64. So this patch also
reduces confusion for people who grep the tree and might previously
have thought that arm64 used this code.
Signed-off-by: Andy Lutomirski
---
include/linux/entry-common.h | 41
kernel/entry/common.c| 10
Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 23 ++
arch/x86/entry/entry_32.S| 51 +---
arch/x86/entry/entry_64.S| 33 +
arch/x86/include/asm/switch_to.h | 2 +-
arch/x86/kernel
copy_from_user_nmi() validates that the pointer is in the user range,
so there is no need for an extra check in copy_code().
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel
of fetch failed. This makes it much easier to understand what's happening.
Cc: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 4 ++--
arch/x86/kernel/process.c | 13 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel
work involved a small change to
ret_from_fork, and adjusting the asm is a mess. So C it is.
Changes from v3: Get rid of arm64 special cases
Changes from v1 and v2: Complete rewrite
Andy Lutomirski (9):
x86/dumpstack: Remove unnecessary range check fetching opcode bytes
x86/kthread,dumpstack
On Wed, Mar 17, 2021 at 9:27 AM Peter Zijlstra wrote:
>
> On Wed, Mar 17, 2021 at 11:55:22PM +0900, Masami Hiramatsu wrote:
> > Hi Andy,
> >
> > Would you think you still need this series to remove iret to kernel?
>
> They're an improvement anyway, let me queue them so that they don't get
> lost.
On Mon, Mar 8, 2021 at 2:06 AM Mark Rutland wrote:
>
> On Thu, Mar 04, 2021 at 11:06:00AM -0800, Andy Lutomirski wrote:
> > exit_to_user_mode() does part, but not all, of the exit-to-user-mode work.
> > It's used only by arm64, and arm64 should stop using it (hint, hint!).
Your warning is odd, but I see the bug. It's in KVM.
On Thu, Mar 11, 2021 at 4:37 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:05a59d79 Merge git://git.kernel.org:/pub/scm/linux/kernel/..
> git tree: upstream
> console output:
On Wed, Mar 10, 2021 at 5:19 PM Aili Yao wrote:
>
> On Mon, 8 Mar 2021 11:00:28 -0800
> Andy Lutomirski wrote:
>
> > > On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
> > >
> > >
> > >>
> > >> Can you point me at that SIGB
> On Mar 8, 2021, at 10:31 AM, Luck, Tony wrote:
>
>
>>
>> Can you point me at that SIGBUS code in a current kernel?
>
> It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever
> get_user()
> or copy from user variant was in use in the kernel when the poison memory was
> On Mar 8, 2021, at 1:49 AM, Aili Yao wrote:
>
> On Sun, 7 Mar 2021 11:16:24 -0800
> Andy Lutomirski wrote:
>
>>>>>>> Some programs may use read(2), write(2), etc as ways to check if
>>>>>>> memory is valid without getting a
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 3fb0fdb3bbe7aed495109b3296b06c2409734023
Gitweb:
https://git.kernel.org/tip/3fb0fdb3bbe7aed495109b3296b06c2409734023
Author:Andy Lutomirski
AuthorDate:Sat, 13 Feb 2021 11:19:44 -08:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: d0962f2b24c99889a386f0658c71535f56358f77
Gitweb:
https://git.kernel.org/tip/d0962f2b24c99889a386f0658c71535f56358f77
Author:Andy Lutomirski
AuthorDate:Sat, 13 Feb 2021 11:19:45 -08:00
On Wed, Mar 3, 2021 at 4:51 AM Aili Yao wrote:
>
> On Wed, 3 Mar 2021 20:24:02 +0800
> Aili Yao wrote:
>
> > On Mon, 1 Mar 2021 11:09:36 -0800
> > Andy Lutomirski wrote:
> >
> > > > On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote:
> > > >
&g
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 5d5675df792ff67e74a500c4c94db0f99e6a10ef
Gitweb:
https://git.kernel.org/tip/5d5675df792ff67e74a500c4c94db0f99e6a10ef
Author:Andy Lutomirski
AuthorDate:Thu, 04 Mar 2021 11:05:54 -08:00
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e59ba7bf71a09e474198741563e0e587ae43d1c7
Gitweb:
https://git.kernel.org/tip/e59ba7bf71a09e474198741563e0e587ae43d1c7
Author:Andy Lutomirski
AuthorDate:Thu, 04 Mar 2021 11:05:54 -08:00
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: dabf017539988a9bfc40a38dbafd35c501bacc44
Gitweb:
https://git.kernel.org/tip/dabf017539988a9bfc40a38dbafd35c501bacc44
Author:Andy Lutomirski
AuthorDate:Thu, 04 Mar 2021 11:05:54 -08:00
If arch code calls the wrong kernel entry helpers, syscall entries and
exits can get out of sync. Add a new field to task_struct to track the
syscall state and validate that it transitions correctly.
Signed-off-by: Andy Lutomirski
---
include/linux/sched.h | 4
init/init_task.c | 8
(). It's also only used by arm64. Give it
the same treatment.
Signed-off-by: Andy Lutomirski
---
include/linux/entry-common.h | 34 ++
kernel/entry/common.c| 4
2 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/include/linux/entry-common.h
-by: Andy Lutomirski
---
arch/x86/kernel/traps.c | 4 ++--
include/asm-generic/bug.h | 8
include/linux/instrumentation.h | 25 -
kernel/entry/common.c | 7 +++
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel
of the kentry
code, and trying to debug the resulting state machine will be painful.
arm64 can turn it back on when it starts using the entire generic
path.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig.debug | 10 --
lib/Kconfig.debug | 11 +++
2 files changed, 11
It's quite easy to mess up kentry calls. Add debgging checks that kentry
transitions to and from user mode match up and that kentry_nmi_enter() and
kentry_nmi_exit() match up.
Checking full matching of kentry_enter() with kentry_exit() needs
per-task state.
Signed-off-by: Andy Lutomirski
Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 23 ++
arch/x86/entry/entry_32.S| 51 +---
arch/x86/entry/entry_64.S| 33 +
arch/x86/include/asm/switch_to.h | 2 +-
arch/x86/kernel
The new common syscall API had a large and confusing API surface. Simplify
it. Now there is exactly one way to use it. It's a bit more verbose than
the old way for the simple x86_64 native case, but it's much easier to use
right, and the diffstat should speak for itself.
Signed-off-by: Andy
copy_from_user_nmi() validates that the pointer is in the user range,
so there is no need for an extra check in copy_code().
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel
contemplate
changing that later. That code predates the common entry code.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 8 ++---
arch/x86/include/asm/idtentry.h | 28 +++
arch/x86/kernel/cpu/mce/core.c | 10 +++---
arch/x86/kernel/kvm.c | 6 ++--
arch
1 - 100 of 19466 matches
Mail list logo
