de/asm/thread_info.h file.
>
> Fixes: 6342adcaa683 ("entry: Ensure trap after single-step on system call
> return"
> CC: Kyle Huey
> Signed-off-by: Sedat Dilek
> ---
> arch/x86/include/asm/thread_info.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --g
On Sun, Feb 7, 2021 at 3:09 PM Sedat Dilek wrote:
>
> Hi,
>
> congrats to Linux v5.11-rc7.
>
> after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> system call return"):
>
> $ git grep '\_TIF_SINGLESTEP' arch/x86/
> arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
> (1
On Wed, Feb 3, 2021 at 10:11 AM Kyle Huey wrote:
>
> On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
> wrote:
> > This seems to pass Kyle's test case. Kyle, can you verify it works with
> > rr?
>
> I will test it later today.
I have verified that a) the
On Wed, Feb 3, 2021 at 10:00 AM Gabriel Krisman Bertazi
wrote:
>
> Linus Torvalds writes:
>
> > On Sun, Jan 31, 2021 at 3:35 PM Linus Torvalds
> > wrote:
> >>
> >> I wonder if the simple solution is to just
> >>
> >> (a) always set one of the SYSCALL_WORK_EXIT bits on the child in
> >> ptrace (
On Sun, Jan 31, 2021 at 3:36 PM Andy Lutomirski wrote:
> > The odd system call tracing part I have no idea who depends on it
> > (apparently "rr", which I assume is some replay thing), and I suspect
> > our semantics for it has been basically random historical one, and
> > it's apparently what cha
On Sun, Jan 31, 2021 at 2:27 PM Kyle Huey wrote:
>
> On Sun, Jan 31, 2021 at 2:20 PM Andy Lutomirski wrote:
> >
> >
> >
> > > On Jan 31, 2021, at 2:08 PM, Kyle Huey wrote:
> > >
> > > On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski
&g
On Sun, Jan 31, 2021 at 2:20 PM Andy Lutomirski wrote:
>
>
>
> > On Jan 31, 2021, at 2:08 PM, Kyle Huey wrote:
> >
> > On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski
> > wrote:
> >> Indeed, and I have tests for this.
> >
> > Do you mean
On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski wrote:
> Indeed, and I have tests for this.
Do you mean you already have a test case or that you would like a
minimized test case?
- Kyle
On Sat, Jan 30, 2021 at 5:56 PM Linus Torvalds
wrote:
>
> On Sat, Jan 30, 2021 at 5:32 PM Kyle Huey wrote:
> >
> > I tested that with 2991552447707d791d9d81a5dc161f9e9e90b163 reverted
> > and Yuxuan's patch applied to Linus's tip rr works and passes all
> >
Yuxuan Shui previous reported a regression in single step reporting,
introduced in 64eb35f701f04b30706e21d1b02636b5d31a37d2, with a patch
to fix it.
However, after that is fixed, there is another regression introduced
later in the same series, in 2991552447707d791d9d81a5dc161f9e9e90b163,
that agai
On Thu, Jan 28, 2021 at 11:10 AM Linus Torvalds
wrote:
> You should have pointed to the actual patch.
Sorry, I broke the reply threading in my mail client.
- Kyle
Hey everyone,
This regression[0] has totally broken rr on 5.11. Could we get someone
to look at and merge Yuxuan's patch here?
- Kyle
[0] https://github.com/rr-debugger/rr/issues/2793
nfortunately we lost DR_STEP for PTRACE_{BLOCK,SINGLE}STEP.
>
> Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to
> thread.virtual_dr6")
> Reported-by: Kyle Huey
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/include/asm/ptrace.h |2 ++
&g
make it
> conditional on in_compat_syscall().
>
> Fixes: c3973b401ef2 ("mm: remove compat_process_vm_{readv,writev}")
> Reported-by: Kyle Huey
> Signed-off-by: Jens Axboe
>
> ---
>
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
>
A test program from the rr[0] test suite, vm_readv_writev[1], no
longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
on a 64 bit kernel. The first process_vm_readv call (on line 35) now
fails with EFAULT. I have bisected this to
c3973b401ef2b0b8005f8074a10e96e3ea093823.
It shoul
On Mon, Oct 26, 2020 at 10:18 AM Peter Zijlstra wrote:
>
> On Mon, Oct 26, 2020 at 10:12:30AM -0700, Kyle Huey wrote:
> > On Mon, Oct 26, 2020 at 9:55 AM Peter Zijlstra wrote:
> > > @@ -935,6 +936,26 @@ static __always_inline void exc_debug_user(struct
On Mon, Oct 26, 2020 at 9:55 AM Peter Zijlstra wrote:
>
> On Mon, Oct 26, 2020 at 05:31:00PM +0100, Peter Zijlstra wrote:
> > In that respect, I think the current virtual_dr6 = 0 is placed wrong, it
> > should only be in exc_debug_user(). The only 'problem' then is that we
> > seem to be able to l
On Mon, Oct 26, 2020 at 9:05 AM Peter Zijlstra wrote:
>
> On Mon, Oct 26, 2020 at 04:55:21PM +0100, Peter Zijlstra wrote:
> > On Mon, Oct 26, 2020 at 07:33:08AM -0700, Kyle Huey wrote:
> > > After resuming a ptracee with PTRACE_SINGLESTEP, in the following
> > >
On Mon, Oct 26, 2020 at 8:55 AM Peter Zijlstra wrote:
> Urgh, now I have to try and remember how all that worked again ...
Sorry.
> I suspect it's either one (or both) of the last two:
>
> f4956cf83ed1 ("x86/debug: Support negative polarity DR6 bits")
> d53d9bc0cf78 ("x86/debug: Change threa
After resuming a ptracee with PTRACE_SINGLESTEP, in the following
ptrace stop retrieving the dr6 value for the tracee gets a value that
does not include DR_STEP (it is in fact always DR6_RESERVED). I
bisected this to the 13cb73490f475f8e7669f9288be0bcfa85399b1f merge. I
did not bisect further.
I d
ported-by: Michael Ellerman
> Fixes: d88d59b64ca3 ("core/entry: Respect syscall number rewrites")
> Cc: Thomas Gleixner
> Cc: Kyle Huey
> Cc: Andy Lutomirski
> Cc: Ingo Molnar
> Signed-off-by: Kees Cook
> ---
> kernel/entry/common.c | 6 --
> 1 file
On Mon, Aug 31, 2020 at 12:37 PM Kees Cook wrote:
>
> On Fri, Aug 28, 2020 at 09:56:13PM -0400, Rich Felker wrote:
> > Asynchronous termination of a thread outside of the userspace thread
> > library's knowledge is an unsafe operation that leaves the process in
> > an inconsistent, corrupt, and po
On Tue, Aug 25, 2020 at 12:32 PM Andy Lutomirski wrote:
>
> On Tue, Aug 25, 2020 at 11:50 AM Kyle Huey wrote:
> >
> > On Tue, Aug 25, 2020 at 10:31 AM Kyle Huey wrote:
> > >
> > > On Tue, Aug 25, 2020 at 9:46 AM Andy Lutomirski wrote:
> > > >
&
On Tue, Aug 25, 2020 at 10:31 AM Kyle Huey wrote:
>
> On Tue, Aug 25, 2020 at 9:46 AM Andy Lutomirski wrote:
> >
> > On Tue, Aug 25, 2020 at 9:32 AM Kyle Huey wrote:
> > >
> > > On Tue, Aug 25, 2020 at 9:12 AM Andy Lutomirski
> > > wrote:
> >
On Tue, Aug 25, 2020 at 9:46 AM Andy Lutomirski wrote:
>
> On Tue, Aug 25, 2020 at 9:32 AM Kyle Huey wrote:
> >
> > On Tue, Aug 25, 2020 at 9:12 AM Andy Lutomirski wrote:
> > > I don’t like this at all. Your behavior really shouldn’t depend on
> > > whethe
On Tue, Aug 25, 2020 at 9:12 AM Andy Lutomirski wrote:
> I don’t like this at all. Your behavior really shouldn’t depend on
> whether the new instructions are available. Also, some day I would
> like to change Linux to have the new behavior even if FSGSBASE
> instructions are not available, and t
On Mon, Aug 24, 2020 at 5:31 PM Andy Lutomirski wrote:
>
> On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin wrote:
> >
> > On 2020-08-24 14:10, Andy Lutomirski wrote:
> > >
> > > PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
> > >
> > > PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS an
On Fri, Aug 21, 2020 at 7:53 PM Andy Lutomirski wrote:
>
>
>
> > On Aug 21, 2020, at 2:33 PM, Kyle Huey wrote:
> >
> > On Fri, Aug 21, 2020 at 1:08 PM Bae, Chang Seok
> > wrote:
> >>
> >>
> >>>> On Aug 20, 2020, at 21:41, Kyl
On Fri, Aug 21, 2020 at 1:08 PM Bae, Chang Seok
wrote:
>
>
> > On Aug 20, 2020, at 21:41, Kyle Huey wrote:
> >
> > On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
> > running under rr[0]. Booting the kernel with `nofsgsbase` fixes it an
On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
running under rr[0]. Booting the kernel with `nofsgsbase` fixes it and
I bisected to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.8&id=673903495c85137791d5820d690229efe09c8f7b.
STR:
1. Build r
On Wed, Aug 19, 2020 at 12:44 PM Thomas Gleixner wrote:
>
> On Wed, Aug 19 2020 at 10:14, Kyle Huey wrote:
> > tl;dr: after 27d6b4d14f5c3ab21c4aef87dd04055a2d7adf14 ptracer
> > modifications to orig_ax in a syscall entry trace stop are not honored
> > and this breaks our
On Wed, Aug 19, 2020 at 11:42 AM wrote:
>
> On Wed, Aug 19, 2020 at 10:53:58AM -0700, Kyle Huey wrote:
> > rr, a userspace record and replay debugger[0], has a test suite that
> > attempts to exercise strange corners of the Linux API. One such
> > tes
rr, a userspace record and replay debugger[0], has a test suite that
attempts to exercise strange corners of the Linux API. One such
test[1] began failing after 2bbc68f8373c0631ebf137f376fbea00e8086be7.
I have not tried to understand what has changed in the kernel here but
since the commit message
tl;dr: after 27d6b4d14f5c3ab21c4aef87dd04055a2d7adf14 ptracer
modifications to orig_ax in a syscall entry trace stop are not honored
and this breaks our code.
rr, a userspace record and replay debugger[0], redirects syscalls of
its ptracee through an in-process LD_PRELOAD-injected solib. To do
thi
On Thu, Mar 14, 2019 at 7:50 PM Xiaoyao Li wrote:
>
> CPUID Faulting is a feature about CPUID instruction. When CPUID Faulting is
> enabled, all execution of the CPUID instruction outside system-management
> mode (SMM) cause a general-protection (#GP) if the CPL > 0.
>
> About this feature, detail
On Wed, Nov 21, 2018 at 12:14 AM Peter Zijlstra wrote:
>
> On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > > independent counters, because while one counter overflows, we'll stall
> > > counting on all others unti
On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote:
>
> > I suppose that's fair that it's better for some use cases. The flip
> > side is that it's no longer possible to get exactly accurate counts
> > from user space if you're using the PMI (because any events between
> > the overflow itself and th
On Tue, Nov 20, 2018 at 1:19 PM Stephane Eranian wrote:
>
> On Tue, Nov 20, 2018 at 12:53 PM Kyle Huey wrote:
> >
> > On Tue, Nov 20, 2018 at 12:11 PM Andi Kleen wrote:
> > >
> > > > > > Given that we're already at rc3, and that this rend
On Tue, Nov 20, 2018 at 12:11 PM Andi Kleen wrote:
>
> > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > we'd ask that counter freezing be disabled for the 4.20 release.
> > >
> > > The boot option should be good enough for the release?
> >
> > I'm not entirely sure
On Tue, Nov 20, 2018 at 11:41 AM Andi Kleen wrote:
>
> > rr, a userspace record and replay debugger[0], uses the PMU interrupt
> > (PMI) to stop a program during replay to inject asynchronous events
> > such as signals. With perf counter freezing enabled we are reliably
> > seeing perf event overc
On Tue, Nov 20, 2018 at 10:16 AM Stephane Eranian wrote:
> I would like to understand better the PMU behavior you are relying upon and
> why the V4 freeze approach is breaking it. Could you elaborate?
I investigated a bit more to write this response and discovered that
my initial characterization
tl;dr: rr is currently broken on 4.20rc2, which I bisected to
af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
rr to work.
rr, a userspace record and replay debugger[0], uses the PMU interrupt
(PMI) to stop a
ffing some fields because:
>
> 1. Keeping the skid info should allow us to look at that if we have
> interesting later.
>
> 2. Not sure if 0-stuffing some fields has potential conflicts with some
> applications.
>
> Is this proposal reasonable?
>
> Thanks
> Jin Yao
>
>
&g
On Thu, Jun 14, 2018 at 10:11 PM, Jin, Yao wrote:
>
>
> On 6/15/2018 11:35 AM, Kyle Huey wrote:
>>
>> I strongly object to this patch as written. As I said when I
>> originally reported[0] the regression introduced by the previous
>> version of this patch a ye
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
int
On Mon, Nov 13, 2017 at 6:53 AM, Oleg Nesterov wrote:
> ping...
>
> Dmitry confirms this actually fixes the problem reported by syzkaller
> we discussed in another thread.
>
>
> On 11/03, Oleg Nesterov wrote:
>>
>> On 11/02, Oleg Nesterov wrote:
>> >
>> > I need to write the changelog, and perhaps
On Sat, Oct 28, 2017 at 1:20 PM, Andy Lutomirski wrote:
> Answering both emails here.
>
> Also, welcome Kyle. Kyle, how badly does rseq's proposed
> event_counter break rr? For that matter, how badly does rseq without
> an event_counter break rr?
>
> (Linus, if you care, I'm proposing that rseq
On Tue, Oct 10, 2017 at 8:35 PM, Wanpeng Li wrote:
> Hi Kyle,
> 2017-03-20 16:16 GMT+08:00 Kyle Huey :
>> Test disabling and reenabling the cpuid instruction via the new arch_prctl
>> ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
>> expected beh
Could we get this patch into the next 4.14 rc too? This "typo" causes a bunch
of sections in /proc/N/maps to be incorrectly labelled [mpx] which confuses rr.
We could probably work around if it we had to but doing this right is trivial.
Thanks,
- Kyle
Beginning with 553f770ef71b, the following program fails when compiled
for 32 bit and executed on a 64 bit kernel and succeeds when compiled
for and executed on a 64 bit. It continues to fail even after
58aff0af7573. When compiled as 32 bit, an shmctl call fails with
EBADR (see the XXX comment).
On Tue, Jul 11, 2017 at 8:32 AM, Kyle Huey wrote:
> On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote:
>>
>> * Kyle Huey wrote:
>>
>>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan
>>> wrote:
>>> > On Tue, Jul 4, 2017 at 3:21 AM,
On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote:
>
> * Kyle Huey wrote:
>
>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan
>> wrote:
>> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote:
>> >> Should any of those be moved into the
On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote:
> On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote:
>> Should any of those be moved into the "should be dropped" pile?
>
> Why not be conservative and clear every sample you're not sure about?
>
> We'd appreciate a fix sooner rather than
On Wed, Jun 28, 2017 at 3:55 PM, Kyle Huey wrote:
> On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote:
>> On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote:
>>> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote:
>>> > @@ -6101,6 +6116,12 @@ v
On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote:
> On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote:
>> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote:
>> > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header
>> > *
On Wed, Jun 28, 2017 at 10:19 AM, Mark Rutland wrote:
> On Wed, Jun 28, 2017 at 09:46:43AM -0700, Kyle Huey wrote:
>> On Wed, Jun 28, 2017 at 3:12 AM, Mark Rutland wrote:
>> > On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote:
>> >> My understanding
On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote:
> On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote:
>> On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote:
>
>> As we're trying to avoid smapling state, I think we can move the check
>>
On Wed, Jun 28, 2017 at 3:12 AM, Mark Rutland wrote:
> On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote:
>> On Tue, Jun 27, 2017 at 7:09 PM, Jin, Yao wrote:
>> > Hi,
>> >
>> > In theory, the PMI interrupts in skid region should be dropped, right?
that `perf_event_fasync` is what must run to deliver our
signal, while the `overflow_handler` is what copies the kernel RIP/etc
into the output buffer that you want to skip.
- Kyle
> Anyway let's listen to more comments from community.
>
> Thanks
>
> Jin Yao
>
>
>
>
nd this question, but hopefully the above clarified things.
- Kyle
> Thanks
> Jin Yao
>
>
> On 6/28/2017 9:01 AM, Kyle Huey wrote:
>>
>> Sent again with LKML CCd, sorry for the noise.
>>
>> - Kyle
>>
>> On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey
Sent again with LKML CCd, sorry for the noise.
- Kyle
On Tue, Jun 27, 2017 at 5:38 PM, Kyle Huey wrote:
> cc1582c231ea introduced a regression in v4.12.0-rc5, and appears to be
> a candidate for backporting to stable branches.
>
> rr, a userspace record and replay debugger[0],
On Thu, Mar 23, 2017 at 8:18 AM, Arnd Bergmann wrote:
> sys_arch_prctl is only provided on x86, and there is no reason
> to add it elsewhere. However, including it on the 32-bit syscall
> table caused a warning for most configurations on non-x86:
>
> :1328:2: warning: #warning syscall arch_prctl n
On Tue, Mar 21, 2017 at 1:34 AM, Ingo Molnar wrote:
>
> * tip-bot for Kyle Huey wrote:
>
>> Commit-ID: e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
>> Gitweb:
>> http://git.kernel.org/tip/e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
>> Author: Kyle Huey
>
Commit-ID: d582799fe5de1c1ca127d7f364db12a660cf46d4
Gitweb: http://git.kernel.org/tip/d582799fe5de1c1ca127d7f364db12a660cf46d4
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 16:05:35 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 21 Mar 2017 10:08:29 +0100
um/arch_prctl: Fix
Oops.
Signed-off-by: Kyle Huey
---
arch/x86/um/syscalls_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
index 81b9fe100f7c..58f51667e2e4 100644
--- a/arch/x86/um/syscalls_64.c
+++ b/arch/x86/um/syscalls_64.c
@@ -12,7
On Mon, Mar 20, 2017 at 8:00 AM, Thomas Gleixner wrote:
> On Mon, 20 Mar 2017, Kyle Huey wrote:
>> --- a/arch/x86/include/uapi/asm/prctl.h
>> +++ b/arch/x86/include/uapi/asm/prctl.h
>> @@ -6,8 +6,17 @@
>> #define ARCH_GET_FS 0x1003
>> #define ARCH_GET_GS 0x1
Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.
On UML, simply stub out this syscall.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel
Add do_arch_prctl_common() to handle arch_prctls that are not specific to 64
bit mode. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/proto.h
arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're
adding additional options, fix that.
Signed-off-by: Kyle Huey
---
arch/um/include/shared/os.h | 4 ++--
arch/x86/include/asm/proto.h | 2 +-
arch/x86/kernel/process_64.c | 8
arc
Use the SYSCALL_DEFINE2 macro instead of manually defining it.
Signed-off-by: Kyle Huey
---
arch/x86/kernel/process_64.c | 3 ++-
arch/x86/um/syscalls_64.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64(). Also rename the second
argument to arch_prctl(), which will no longer always be an address.
Signed-off-by: Kyle Huey
Reviewed-by: Andy Lutomirski
---
arch/um/include
ure. It is
documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/
DEV if CPUID faulting is not supported on
this system.
The state of the CPUID faulting flag is propagated across forks, but reset
upon exec.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 2 +
arch/x86/include/asm/processor.h | 2 +
arch/x86/include/asm/thread_info.h |
Commit-ID: e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
Gitweb: http://git.kernel.org/tip/e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:26 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:34 +0100
x86/arch_prctl: Add ARCH_
Commit-ID: 79170fda313ed5be2394f87aa2a00d597f8ed4a1
Gitweb: http://git.kernel.org/tip/79170fda313ed5be2394f87aa2a00d597f8ed4a1
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:24 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:33 +0100
x86/syscalls/32: Wire up
Commit-ID: 90218ac77d0582eaf2d0872d8d900cbd5bf1f205
Gitweb: http://git.kernel.org/tip/90218ac77d0582eaf2d0872d8d900cbd5bf1f205
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:25 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:34 +0100
x86/cpufeature: Detect
Commit-ID: ff3f097eef30151f5ee250859e0fe8a0ec02c160
Gitweb: http://git.kernel.org/tip/ff3f097eef30151f5ee250859e0fe8a0ec02c160
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:21 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:32 +0100
x86/arch_prctl/64: Use
Commit-ID: ab6d9468631a6e56e4c071c6ce6710956485fe08
Gitweb: http://git.kernel.org/tip/ab6d9468631a6e56e4c071c6ce6710956485fe08
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:19 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:32 +0100
x86/msr: Rename
Commit-ID: b0b9b014016d16ca7a192da986aa8ebae21bb995
Gitweb: http://git.kernel.org/tip/b0b9b014016d16ca7a192da986aa8ebae21bb995
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:23 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:33 +0100
x86/arch_prctl: Add
Commit-ID: dd93938a92dc067aba70c401bdf2e50ed58083db
Gitweb: http://git.kernel.org/tip/dd93938a92dc067aba70c401bdf2e50ed58083db
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:20 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:32 +0100
x86/arch_prctl: Rename
Commit-ID: 17a6e1b8e8e8539f89156643f8c3073f09ec446a
Gitweb: http://git.kernel.org/tip/17a6e1b8e8e8539f89156643f8c3073f09ec446a
Author: Kyle Huey
AuthorDate: Mon, 20 Mar 2017 01:16:22 -0700
Committer: Thomas Gleixner
CommitDate: Mon, 20 Mar 2017 16:10:32 +0100
x86/arch_prctl/64: Rename
Test disabling and reenabling the cpuid instruction via the new arch_prctl
ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
expected behaviors across fork() and exec().
Signed-off-by: Kyle Huey
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing
.
kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey
Reviewed-by: David Matlack
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c| 3 +++
arch/x86/kvm/cpuid.h| 11 +++
arch/x86/kvm/emulate.c | 7 +++
arch
This matches the only public Intel documentation of this MSR, in the
"Virtualization Technology FlexMigration Application Note"
(preserved at https://bugzilla.kernel.org/attachment.cgi?id=243991)
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 6 +++---
arch/x86/
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by provi
On Tue, Mar 14, 2017 at 1:36 PM, Thomas Gleixner wrote:
> On Sat, 11 Mar 2017, Kyle Huey wrote:
>> static void init_intel_misc_features(struct cpuinfo_x86 *c)
>> {
>> u64 msr;
>>
>> + if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &msr))
>>
On Tue, Mar 14, 2017 at 1:07 PM, Thomas Gleixner wrote:
> On Sat, 11 Mar 2017, Kyle Huey wrote:
>
>> arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're
>> adding additional options, fix that.
>
> And why is that at
On Thu, Mar 16, 2017 at 4:09 AM, Michael Ellerman wrote:
> Linus Torvalds writes:
>
>> Kyle,
>> your patch format is really odd.
>>
>> You seem to have *eight* lines of context rather than the regular 3.
>> Is there any reason for that oddity?
>>
>> It basically means that a one-line hunk ends u
On Tue, Mar 14, 2017 at 12:01 PM, H. Peter Anvin wrote:
> On 11/08/16 10:39, Kyle Huey wrote:
>> }
>>
>> + if (test_tsk_thread_flag(prev_p, TIF_NOCPUID) ^
>> + test_tsk_thread_flag(next_p, TIF_NOCPUID)) {
>> + set_cpuid_fau
Use the SYSCALL_DEFINE2 macro instead of manually defining it.
Signed-off-by: Kyle Huey
---
arch/x86/kernel/process_64.c | 3 ++-
arch/x86/um/syscalls_64.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're
adding additional options, fix that.
Signed-off-by: Kyle Huey
---
arch/um/include/shared/os.h | 2 +-
arch/x86/include/asm/proto.h | 4 ++--
arch/x86/kernel/
DEV if CPUID faulting is not supported on
this system.
The state of the CPUID faulting flag is propagated across forks, but reset
upon exec.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 3 ++
arch/x86/include/asm/processor.h | 2 +
arch/x86/include/asm/thread_info.h |
Test disabling and reenabling the cpuid instruction via the new arch_prctl
ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
expected behaviors across fork() and exec().
Signed-off-by: Kyle Huey
---
tools/testing/selftests/x86/Makefile | 4 +-
tools/testing
.
kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey
Reviewed-by: David Matlack
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c| 3 +++
arch/x86/kvm/cpuid.h| 11 +++
arch/x86/kvm/emulate.c | 7 +++
arch
Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.
On UML, simply stub out this syscall.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by prov
ure. It is
documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/
In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64(). Also rename the second
argument to arch_prctl(), which will no longer always be an address.
Signed-off-by: Kyle Huey
Reviewed-by: Andy Lutomirski
---
arch/um/include
Add do_arch_prctl_common() to handle arch_prctls that are not specific to 64
bit mode. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/proto.h
Commit-ID: b9894a2f5bd18b1691cb6872c9afe32b148d0132
Gitweb: http://git.kernel.org/tip/b9894a2f5bd18b1691cb6872c9afe32b148d0132
Author: Kyle Huey
AuthorDate: Tue, 14 Feb 2017 00:11:03 -0800
Committer: Thomas Gleixner
CommitDate: Sat, 11 Mar 2017 12:45:18 +0100
x86/process: Correct and
1 - 100 of 265 matches
Mail list logo
