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 /sys/k
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 /sys/kernel/debug/selftest_he
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 ma
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 o
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:
d
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 actual
> 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 x86-specific
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 k
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 ope
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 driv
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 tes
12 matches
Mail list logo
