linux-kernel - Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKv+Gu9U5Ap37J-56=oDOuUfbcMyGaMnTZh1+JKHDTPU5pteZQ@mail.gmail.com>
Date:   Sun, 27 May 2018 14:28:26 +0200
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>
Cc:     "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lee Chun-Yi <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
        "Luck, Tony" <tony.luck@...el.com>,
        Will Deacon <will.deacon@....com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Mark Rutland <mark.rutland@....com>,
        Bhupesh Sharma <bhsharma@...hat.com>,
        Naresh Bhat <naresh.bhat@...aro.org>,
        "Neri, Ricardo" <ricardo.neri@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 27 May 2018 at 10:37, Prakhya, Sai Praneeth
<sai.praneeth.prakhya@...el.com> wrote:
>> > One more question again, if we are sure that non-blocking variants
>> > will _always_ be called in atomic context, then, we got it covered.
>> > Because, in
>> > set_variable() and query_variable_info() (both blocking and
>> > non-blocking) we check for in_atomic() and if so, we don't use efi_rts_wq
>> (please refer to patch 3).
>> >
>> > If you think, there might be a probability of calling non-blocking
>> > efi_rts out of atomic context, then, sure! Let's make them never use
>> efi_rts_wq.
>> >
>>
>> This is not about what happens to be the current situation. It is about the API.
>>
>> The non-blocking functions should never block, period. They either fail gracefully
>> or perform their duties without sleeping.
>
> Yes, that makes sense.
>
>>
>> In this particular case, I think it is useful to have a guaranteed non-blocking
>> version, not only to delete the dummy EFI variable, but potentially in other
>> future cases as well, given that they can be called much earlier in the boot (when
>> the perf/%cr3 issue is not a concern to begin with)
>
> Thanks for making it more clear :)
> I will change the non-blocking variants _not_ to use efi_rts_wq and as you suggested
> make efi_delete_dummy_variable() use non-blocking variants (that should also make it
> local to arch/x86).
>

Yes, please.

> Another follow on question is, does every firmware support both blocking and
> non-blocking variants (specially legacy EFI firmware)? I am worried about
> this because, presently efi_delete_dummy_variable() uses set_variable() and
> query_variable_info() but if I change efi_delete_dummy_variable() to use non-blocking
> variants and if they aren’t supported, then, I guess, efi_delete_dummy_variable() might
> fail :(
>
> So, could you please clarify on that?
>

I don't follow. Why should it make any difference to the firmware
whether the OS routines blocks or gives up? We always honor the mutual
exclusion between different invocations of runtime services, and the
firmware itself has no awareness of the kind of scheduling the OS
needs to do to ensure this.