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, A
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 explic
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 requir
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 actually works as
>>> advertised. This may req
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.
This is interesting. Wh
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 PR
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 emulat
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 would allow us to a) mas
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 portabil
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 - MISC_FEAT
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) a
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)
msr_s
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 w
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 (e.
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
18 matches
Mail list logo
