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
ure. It is
documented in detail in Section 2.3.2 of
http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed
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
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
index 63236d8..4d6363c 100644
--- a/arch/x86/kernel/process_64.c
is
another value or 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 | 1 +
arch/x86/include/asm/thread_info.h| 6 +-
arch/
Add a new do_arch_prctl to handle arch_prctls that are not specific to 64
bits. 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 | 1
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
---
arch/x86/include/asm/proto.h | 4 +++-
arch/x86
On Thu, Sep 22, 2016 at 3:22 PM, Andy Lutomirski wrote:
> On Wed, Sep 21, 2016 at 11:58 AM, Kyle Huey wrote:
>> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
>> When enabled, the processor will fault on attempts to execute the CPUID
>> i
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
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
index 63236d8..4d6363c 100644
--- a/arch/x86/kernel/process_64.c
ure. It is
documented in detail in Section 2.3.2 of
http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed
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
is
another value or 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 | 1 +
arch/x86/include/asm/thread_info.h| 6 +-
arch/
Add do_arch_prctl_common to handle arch_prctls that are not specific to 64
bits. 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 | 1
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/x86/include
On Mon, Sep 12, 2016 at 7:15 AM, Kyle Huey wrote:
> On Mon, Sep 12, 2016 at 2:07 AM, Borislav Petkov wrote:
>> On Sun, Sep 11, 2016 at 05:29:23PM -0700, Kyle Huey wrote:
>>> @@ -2162,6 +2168,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long,
>>> arg2, unsigned
On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote:
> You should explicitly check that, if the
> feature is set under Xen PV, then the MSR actually works as
> advertised. This may require talking to the Xen folks to make sure
> you're testing the right configuration.
This is interesting. Wh
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel/process.c | 80 ++
arch/x86/kernel/process_64.c | 66
3 files changed, 81 insertions(+), 66 deletions(-)
diff --git a
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor does it virtualize it, so it does
not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1
-flexmigration-application-note.pdf
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/asm/thread_info.h| 4 +-
arch/x86/include/uapi/asm/prctl.h | 6 +
arch/x86/kernel/process.c | 81 +++
tools/testing/selftests/x86
(Resending because I screwed up the cover email, sorry about that.)
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 (
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel/process.c | 80 ++
arch/x86/kernel/process_64.c | 66
3 files changed, 81 insertions(+), 66 deletions(-)
diff --git a
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor does it virtualize it, so it does
not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1
Signed-off-by: Kyle Huey
---
man2/arch_prctl.2 | 73 +--
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/man2/arch_prctl.2 b/man2/arch_prctl.2
index 989d369..c388797 100644
--- a/man2/arch_prctl.2
+++ b/man2/arch_prctl.2
-flexmigration-application-note.pdf
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/asm/thread_info.h| 4 +-
arch/x86/include/uapi/asm/prctl.h | 6 +
arch/x86/kernel/process.c | 81 +++
tools/testing/selftests/x86
On Wed, Sep 14, 2016 at 2:29 PM, Dave Hansen
wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Signed-off-by: Kyle Huey
>> ---
>> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
>> arch/x86/kernel/process.c | 80
>> +
On Wed, Sep 14, 2016 at 2:46 PM, Dave Hansen
wrote:
> On 09/14/2016 02:35 PM, Kyle Huey wrote:
>> It's not quite a plain move. To leave the existing arch_prctls only
>> accessible to 64 bit callers, I added the is_32 bit and the four early
>> returns for each existing A
On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work.
On Wed, Sep 14, 2016 at 2:59 PM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> 2016-09-15 0:08 GMT+03:00 Kyle Huey :
>> Signed-off-by: Kyle Huey
>> ---
>> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
>> arch/x86/k
On Wed, Sep 14, 2016 at 3:29 PM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> 2016-09-15 1:08 GMT+03:00 Kyle Huey :
>> On Wed, Sep 14, 2016 at 2:59 PM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>>> 2016-09-15 0:08 GMT+03:00 Kyle Huey :
>>>> Signed-
On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote:
>> Intel supports faulting on the CPUID instruction in newer processors. Bit
>> 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
>> documented in de
On Wed, Sep 14, 2016 at 6:54 PM, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 6:47 PM, Kyle Huey wrote:
>> On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote:
>>> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote:
>
>>>> +
>>>> +int set_cpuid
On Wed, Sep 14, 2016 at 6:17 PM, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize a
On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
>>>> On 15.09.16 at 12:05, wrote:
>> On 14/09/16 22:01, Kyle Huey wrote:
>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>> through writes to the relevant MSR, nor does
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
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
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
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 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 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 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 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
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 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
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
This patch modifies the device tree for tegra124 based devices to enable the
Cortex A15 PMU. The interrupt numbers are taken from NVIDIA TRM
DP-06905-001_v03p. This patch was tested on a Jetson TK1.
Signed-off-by: Kyle Huey
---
arch/arm/boot/dts/tegra124.dtsi | 8
1 file changed, 8
This patch modifies the device tree for tegra124 based devices to enable the
Cortex A15 PMU. The interrupt numbers are taken from NVIDIA TRM
DP-06905-001_v03p. This patch was tested on a Jetson TK1.
Updated for proper ordering and to add interrupt-affinity values.
Signed-off-by: Kyle Huey
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, 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 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 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
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 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
> >
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 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: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 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
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 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
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 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
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
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
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
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
On Sat, Jul 18, 2015 at 6:54 AM, Kyle Huey wrote:
> On Fri, Jul 17, 2015 at 4:59 PM, Thierry Reding
> wrote:
>> On Mon, Jul 13, 2015 at 10:35:45AM -0700, Kyle Huey wrote:
>>> This patch modifies the device tree for tegra124 based devices to enable
>>> the Cortex A
On Fri, Jul 17, 2015 at 4:59 PM, Thierry Reding
wrote:
> On Mon, Jul 13, 2015 at 10:35:45AM -0700, Kyle Huey wrote:
>> This patch modifies the device tree for tegra124 based devices to enable
>> the Cortex A15 PMU. The interrupt numbers are taken from NVIDIA TRM
>> DP-06905-
present if PTRACE_SYSEMU is present. Attempting to use PTRACE_SYSEMU_SINGLESTEP
will fail at runtime on ARM with EIO since there is no single stepping on ARM.
Signed-off-by: Kyle Huey
---
arch/arm/include/asm/thread_info.h | 8 ++--
arch/arm/include/uapi/asm/ptrace.h | 32
t to avoid isolating particular bits, and we simply recompute the
XOR before jumping back if the register was clobbered by the work. Finally,
in either event, additional TIF checks of this form simply become another test
and branch, reducing the overhead of the new check I would like to add.
Signed-off-by:
On Mon, Nov 7, 2016 at 12:13 PM, David Matlack wrote:
> On Sun, Nov 6, 2016 at 12:57 PM, Kyle Huey wrote:
>> Hardware support for faulting on the cpuid instruction is not required to
>> emulate it, because cpuid triggers a VM exit anyways. KVM handles the
>> relevant
>&
e.g. like this
.
kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c| 3 +++
arch/x86/kvm/x86.c | 26 ++
3 files changed, 31 insertions(+)
diff --git a/arch/x86/include
On Tue, Nov 8, 2016 at 9:53 AM, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Kyle Huey wrote:
>> > It will simplify the MSR get/set code, and make it easier to plumb
>> > support for new bits in these MSRs.
>>
>> I'm inclined to do this for MSR_PLATFORM_INF
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
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
index b3760b3..2718cf9 100644
--- a/arch/x86/kernel/process_64.c
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
ure. It is
documented in detail in Section 2.3.2 of
http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed
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/x86/include
.
kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c| 3 +++
arch/x86/kvm/cpuid.h| 10 ++
arch/x86/kvm/x86.c | 25 +
4 files changed
is
another value or 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/incl
Add do_arch_prctl_common to handle arch_prctls that are not specific to 64
bits. 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 | 1
On Tue, Nov 8, 2016 at 11:06 AM, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Kyle Huey wrote:
>
>> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
>> When enabled, the processor will fault on attempts to execute the CPUID
>> instruction with
On Fri, Nov 11, 2016 at 12:54 PM, Nadav Amit wrote:
>
>> On Nov 10, 2016, at 3:40 PM, Kyle Huey wrote:
>>
>> Hardware support for faulting on the cpuid instruction is not required to
>> emulate it, because cpuid triggers a VM exit anyways. KVM handles the
>> re
On Wed, Nov 16, 2016 at 12:42 PM, Paolo Bonzini wrote:
>> On Fri, Nov 11, 2016 at 12:54 PM, Nadav Amit wrote:
>> >
>> >> On Nov 10, 2016, at 3:40 PM, Kyle Huey wrote:
>> >>
>> >> Hardware support for faulting on the cpuid instruction is not req
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
.
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
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
UID 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| 6 +-
arch/x86/include/uapi/asm/prctl.h |
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
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 ++
a
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
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
On Wed, Nov 9, 2016 at 1:47 AM, Borislav Petkov wrote:
> On Tue, Nov 08, 2016 at 10:39:50AM -0800, Kyle Huey wrote:
>
> <--- Add commit message here.
>
>> Signed-off-by: Kyle Huey
>> ---
>> arch/x86/kernel/process_64.c | 3 ++-
>> arch/x86/um/syscalls
On Wed, Nov 9, 2016 at 5:21 AM, Borislav Petkov wrote:
> On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote:
>> The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
>> this function.
>>
>> Stick the call at the end of init_scattered_cpuid_features() for now. I
>> st
On Wed, Nov 9, 2016 at 5:34 AM, Thomas Gleixner wrote:
> On Wed, 9 Nov 2016, Borislav Petkov wrote:
>> +static void init_misc_enables(struct cpuinfo_x86 *c)
>> +{
>> + u64 val, misc_en;
>> +
>> + if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &misc_en))
>> + return;
>> +
>> + m
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
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
.
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/x86.c | 26
UID 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| 6 +-
arch/x86/include/uapi/asm/prctl.h |
1 - 100 of 265 matches
Mail list logo
