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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sun, 27 May 2018 08:37:43 +0000
From:   "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
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

> > 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).

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?

Regards,
Sai