linux-kernel - Queries on ARM SDEI Linux kernel code

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-next>] [day] [month] [year] [list]

Message-ID: <af00fba0-7d1f-6655-906d-1e6a5ae45ede@codeaurora.org>
Date:   Thu, 15 Oct 2020 11:37:07 +0530
From:   Neeraj Upadhyay <neeraju@...eaurora.org>
To:     james.morse@....com
Cc:     linux-arm-kernel@...ts.infradead.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Queries on ARM SDEI Linux kernel code

Hi James,

Have few queries on ARM SDEI Linux code. Queries are listed below; can 
you please help provide your insights on these?

1. Looks like interrupt bind interface (SDEI_1_0_FN_SDEI_INTERRUPT_BIND) 
is not available for clients to use; can you please share information on
why it is not provided?

While trying to dig information on this, I saw  that [1] says:
   Now the hotplug callbacks save  nothing, and restore the OS-view of 
registered/enabled. This makes bound-interrupts harder to work with.

Based on this comment, the changes from v4 [2], which I could understand 
is, cpu down path does not save the current event enable status, and we 
rely on the enable status `event->reenable', which is set, when 
register/unregister, enable/disable calls are made; this enable status 
is used during cpu up path, to decide whether to reenable the interrupt.

Does this make, bound-interrupts harder to work with? how? Can you 
please explain? Or above save/restore is not the reason and you meant 
something else?

Also, does shared bound interrupts also have the same problem, as 
save/restore behavior was only for private events?

2. SDEI_EVENT_SIGNAL api is not provided? What is the reason for it? Its 
handling has the same problems, which are there for bound interrupts?

Also, if it is provided, clients need to register event 0 ? Vendor 
events or other event nums are not supported, as per spec.

3. Can kernel panic() be triggered from sdei event handler? Is it a safe
operation? The spec says, synchronous exceptions should not be 
triggered; I think panic won't do it; but anything which triggers a WARN
or other sync exception in that path can cause undefined behavior. Can 
you share your thoughts on this?

"The handler code should not enable asynchronous exceptions by clearing 
any of the PSTATE.DAIF bits, and should not cause synchronous exceptions 
to the client Exception level."

[1] https://lwn.net/Articles/740817/
[2] https://www.spinics.net/lists/kvm-arm/msg27784.html

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of the Code Aurora Forum, hosted by The Linux Foundation