linux-kernel - Re: [PATCH v2 4/5] prctl: Hook L1D flushing in via prctl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <33b99d83-f2de-6984-c3d6-a44960aac828@amazon.com>
Date:   Thu, 30 Jul 2020 10:13:09 +1000
From:   "Singh, Balbir" <sblbir@...zon.com>
To:     Tom Lendacky <thomas.lendacky@....com>, <tglx@...utronix.de>,
        <linux-kernel@...r.kernel.org>
CC:     <jpoimboe@...hat.com>, <tony.luck@...el.com>,
        <keescook@...omium.org>, <benh@...nel.crashing.org>,
        <x86@...nel.org>, <dave.hansen@...el.com>,
        <torvalds@...ux-foundation.org>, <mingo@...nel.org>
Subject: Re: [PATCH v2 4/5] prctl: Hook L1D flushing in via prctl

On 29/7/20 11:14 pm, Tom Lendacky wrote:
> 
> 
> On 7/28/20 7:11 PM, Balbir Singh wrote:
>> Use the existing PR_GET/SET_SPECULATION_CTRL API to expose the L1D
>> flush capability. For L1D flushing PR_SPEC_FORCE_DISABLE and
>> PR_SPEC_DISABLE_NOEXEC are not supported.
>>
>> There is also no seccomp integration for the feature.
>>
>> Signed-off-by: Balbir Singh <sblbir@...zon.com>
>> ---
>>  arch/x86/kernel/cpu/bugs.c | 54 ++++++++++++++++++++++++++++++++++++++
>>  arch/x86/mm/tlb.c          | 25 +++++++++++++++++-
>>  include/uapi/linux/prctl.h |  1 +
>>  3 files changed, 79 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
>> index 0b71970d2d3d..935ea88313ab 100644
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -295,6 +295,13 @@ enum taa_mitigations {
>>       TAA_MITIGATION_TSX_DISABLED,
>>  };
>>
>> +enum l1d_flush_out_mitigations {
>> +     L1D_FLUSH_OUT_OFF,
>> +     L1D_FLUSH_OUT_ON,
>> +};
>> +
>> +static enum l1d_flush_out_mitigations l1d_flush_out_mitigation __ro_after_init = L1D_FLUSH_OUT_ON;
>> +
>>  /* Default mitigation for TAA-affected CPUs */
>>  static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_VERW;
>>  static bool taa_nosmt __ro_after_init;
>> @@ -378,6 +385,18 @@ static void __init taa_select_mitigation(void)
>>       pr_info("%s\n", taa_strings[taa_mitigation]);
>>  }
>>
>> +static int __init l1d_flush_out_parse_cmdline(char *str)
>> +{
>> +     if (!boot_cpu_has_bug(X86_BUG_L1TF))
>> +             return 0;
> 
> Shouldn't this set the l1d_flush_out_mitigation to L1D_FLUSH_OUT_OFF since
> it is set to L1D_FLUSH_OUT_ON by default? Or does it not matter because
> the enable_l1d_flush_for_task() will return -EINVAL if the cpu doesn't
> have the L1TF bug?
>
> I guess it depends on what you want l1d_flush_out_prctl_set() and
> l1d_flush_out_prctl_get() to return in this case.
> 

Exactly! We want to differentiate between force disabled and not applicable.


Thanks for the review,
Balbir Singh.