On 6/11/20 8:19 AM, Andy Lutomirski wrote:
On Jun 11, 2020, at 2:18 AM, Borislav Petkov wrote:
On Thu, Jun 11, 2020 at 10:36:08AM +0300, Petteri Aimonen wrote:
Hi,
How about putting the file you frob in
/sys/kernel/debug/selftest_helpers/something_or_other. The idea would
be that
On 6/2/20 11:19 PM, Petteri Aimonen wrote:
Hi,
Is it correct to assume the stuff checked differs from test to test
and done in user-space.
undo_evil_state();
Is it correct to assume undoing evil differs from test to test
and done in user-space, provide it can be done from userspace.
Yes,
> On Jun 11, 2020, at 2:18 AM, Borislav Petkov wrote:
>
> On Thu, Jun 11, 2020 at 10:36:08AM +0300, Petteri Aimonen wrote:
>> Hi,
>>
>>> How about putting the file you frob in
>>> /sys/kernel/debug/selftest_helpers/something_or_other. The idea would
>>> be that
On Thu, Jun 11, 2020 at 10:36:08AM +0300, Petteri Aimonen wrote:
> Hi,
>
> > How about putting the file you frob in
> > /sys/kernel/debug/selftest_helpers/something_or_other. The idea would
> > be that /sys/kernel/debug/selftest_helpers would be a general place
> > for kernel helpers needed to
Hi,
> How about putting the file you frob in
> /sys/kernel/debug/selftest_helpers/something_or_other. The idea would
> be that /sys/kernel/debug/selftest_helpers would be a general place
> for kernel helpers needed to make selftests work.
Seems like this is the consensus for now.
Any opinions
Hi,
> Is it correct to assume the stuff checked differs from test to test
> and done in user-space.
>
> > undo_evil_state();
>
> Is it correct to assume undoing evil differs from test to test
> and done in user-space, provide it can be done from userspace.
Yes, currently the test works like:
On 6/2/20 1:50 PM, Andy Lutomirski wrote:
On Jun 2, 2020, at 10:27 AM, Shuah Khan wrote:
On 6/2/20 11:03 AM, Andy Lutomirski wrote:
On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
Hi,
On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
The kernel module is not
> On Jun 2, 2020, at 10:27 AM, Shuah Khan wrote:
>
> On 6/2/20 11:03 AM, Andy Lutomirski wrote:
>>> On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
The kernel module is not actually
On 6/2/20 11:03 AM, Andy Lutomirski wrote:
On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
Hi,
On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
The kernel module is not actually x86-specific, even though it is
currently only enabled for x86. amdgpu driver already does
On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote:
>
> Hi,
>
> On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
> > The kernel module is not actually x86-specific, even though it is
> > currently only enabled for x86. amdgpu driver already does kernel mode
> > floating point
Hi,
> Instead of adding that kernel module which is x86-specific
> to a generic lib/ directory, it should be in, say,
> tools/testing/selftests/x86/test_fpu_module.c or so and instead of
The kernel module is not actually x86-specific, even though it is
currently only enabled for x86. amdgpu
Hi,
On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
> The kernel module is not actually x86-specific, even though it is
> currently only enabled for x86. amdgpu driver already does kernel mode
> floating point operations on PPC64 also, and the same module could be
> used to
Switching to mail where patches are discussed.
> Subject: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()
Fix formatting to:
Subject: [PATCH] x86/fpu: Reset MXCSR to default in kernel_fpu_begin()
> From: Petteri Aimonen
>
> Previously kernel floating point co
13 matches
Mail list logo
