linux-kernel - Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock

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:	Tue, 28 Jul 2015 15:51:22 -0600
From:	Lina Iyer <lina.iyer@...aro.org>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Jeffrey Hugo <jhugo@...eaurora.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for
 hwspinlock_device

On Sat, Jul 18 2015 at 05:31 -0600, Ohad Ben-Cohen wrote:
>Hi Lina,
>
>On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer <lina.iyer@...aro.org> wrote:
>> You are right, RAW capability is not lock specific. But we dont want to
>> impose this on every lock in the bank either.
>
>I'm not sure I'm following your concern here: drivers still need to
>explicitly indicate RAW in order for this to kick in, so this lenient
>approach is not being imposed on them.
>
Correct.

>Your original patch allowed every driver on all platforms to disable
>the sw spinlock mechanism. What I'm merely suggesting is that the
>underlying platform-specific driver should first allow this before it
>is being used, as some vendors prohibit this completely.
>
Agreed. Thats why the platform driver specifies the capability in hwcaps
flag.

>Let's not make this more complicated than needed, so please add the
>hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>could always change this later if it proves to be insufficient.
>
But this could yield wrong locking scenarios. If banks are allowed RAW
capability and is not enforced on a per-lock basis, a driver may lock
using non-raw lock using the _raw API, while another driver may
'acquire' the lock (since the value written to the lock would be the
same as raw api would). That is why you should have the capability on
hwspinlock and not on hwspinlock_device. Locks that are defined are RAW
capable should be used as RAW only.

QCOM platform hwlock #7 is unique that different CPUs trying to acquire
the lock would write different values and hence would be fine. But, the
same is not true for other locks in the bank.

Please let me know if this is not clear.

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/