On 14/09/2016 20:36, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper
> wrote:
>> On 14/09/2016 20:23, Boris Ostrovsky wrote:
>>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey
On 14/09/2016 20:36, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper
> wrote:
>> On 14/09/2016 20:23, Boris Ostrovsky wrote:
>>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
> On Mon, Sep 12, 2016 at 9:56 AM,
On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper
wrote:
> On 14/09/2016 20:23, Boris Ostrovsky wrote:
>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
On Mon, Sep 12, 2016 at 9:56 AM, Andy
On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper
wrote:
> On 14/09/2016 20:23, Boris Ostrovsky wrote:
>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski
wrote:
> You should
On 14/09/2016 19:52, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>> 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
On 14/09/2016 19:52, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>> 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
On 14/09/2016 20:23, Boris Ostrovsky wrote:
> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski
>>> wrote:
You should explicitly check that, if
On 14/09/2016 20:23, Boris Ostrovsky wrote:
> On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>>> 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
On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>> 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
On 09/14/2016 02:52 PM, Andy Lutomirski wrote:
> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
>> 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
On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
> 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
On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote:
> 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
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.
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.
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,
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 long, arg3,
>>> case
On Sep 12, 2016 10:57 AM, "Jann Horn" wrote:
>
> On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> > On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
> > >
> > > rr (http://rr-project.org/), a userspace record-and-replay reverse-
> > > execution
On Sep 12, 2016 10:57 AM, "Jann Horn" wrote:
>
> On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> > On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
> > >
> > > rr (http://rr-project.org/), a userspace record-and-replay reverse-
> > > execution debugger, would like to trap and
On Mon, 12 Sep 2016, Andi Kleen wrote:
> The cpuid char driver does this, other code may too.
Such as anything that calls sync_core().
That includes processor hotplug paths, and who knows what else...
> You probably would need to protect these CPUIDs with an exception
> handler that temporarily
On Mon, 12 Sep 2016, Andi Kleen wrote:
> The cpuid char driver does this, other code may too.
Such as anything that calls sync_core().
That includes processor hotplug paths, and who knows what else...
> You probably would need to protect these CPUIDs with an exception
> handler that temporarily
On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
> >
> > rr (http://rr-project.org/), a userspace record-and-replay reverse-
> > execution debugger, would like to trap and emulate the CPUID instruction.
> > This
On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
> >
> > 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)
Kyle Huey writes:
> 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
Kyle Huey writes:
> 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
On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> This should have a cpufeature bit and show up in /proc/cpuinfo. That
Haha, test a cpufeature with a faulting CPUID :-)
Yeah, we need a synthetic flag and query MSR_PLATFORM_INFO[31] which
denotes whether the other MSR -
On Mon, Sep 12, 2016 at 09:56:11AM -0700, Andy Lutomirski wrote:
> This should have a cpufeature bit and show up in /proc/cpuinfo. That
Haha, test a cpufeature with a faulting CPUID :-)
Yeah, we need a synthetic flag and query MSR_PLATFORM_INFO[31] which
denotes whether the other MSR -
On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
>
> 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
On Sep 11, 2016 5:29 PM, "Kyle Huey" wrote:
>
> 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)
On Mon, Sep 12, 2016 at 07:15:16AM -0700, Kyle Huey wrote:
> Copied from PR_SET_TSC. Would you prefer something like
> disable_cpuid/disable_cpuid_and_set_flag for
> hard_disable_CPUID/disable_CPUID?
Maybe something like this:
switch_cpuid_faulting(bool on)
{
if (on)
On Mon, Sep 12, 2016 at 07:15:16AM -0700, Kyle Huey wrote:
> Copied from PR_SET_TSC. Would you prefer something like
> disable_cpuid/disable_cpuid_and_set_flag for
> hard_disable_CPUID/disable_CPUID?
Maybe something like this:
switch_cpuid_faulting(bool on)
{
if (on)
Thanks for the review!
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:
>> rr (http://rr-project.org/), a userspace record-and-replay reverse-
>> execution debugger, would like to trap and emulate the CPUID
Thanks for the review!
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:
>> rr (http://rr-project.org/), a userspace record-and-replay reverse-
>> execution debugger, would like to trap and emulate the CPUID instruction.
>> This
On Sun, Sep 11, 2016 at 05:29:23PM -0700, Kyle Huey wrote:
> 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
On Sun, Sep 11, 2016 at 05:29:23PM -0700, Kyle Huey wrote:
> 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
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
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
36 matches
Mail list logo