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

Message-ID: <CAK=Wgbaa71BUdsW+etTyGy9DEzDmD0FWnKryyeRV3wUOCfJmvg@mail.gmail.com>
Date:	Sun, 20 Sep 2015 16:02:12 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Lina Iyer <lina.iyer@...aro.org>
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 Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer <lina.iyer@...aro.org> wrote:
> Would you rather query the hwspinlock driver to see if the framework
> should take a s/w spinlock or not, IOW, raw-accessible or not?

Sorry, I'm afraid I rather not. This seems to make things even more
complicated without introducing any technical merit.

>> Let's go over your aforementioned concerns:
>>>
>>> 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
>>
>>
>> If this is allowed by the hardware, then this is a valid scenario.
>> There's no such thing a non-raw lock: a lock is raw if a raw
>> functionality is required.
>>
> Agreed. I believe, we are saying the same thing.
> A raw access is a request from the calling driver. It is a request from
> the driver to directly talk to its hwspinlock driver, without any
> encumberance from the framework.
>
>>> while another driver may
>>> 'acquire' the lock (since the value written to the lock would be the
>>> same as raw api would).
>>
>>
>> Not sure I understand this one. If a lock has already been assigned to
>> a driver, it cannot be re-assigned to another driver.
>>
> Nevermind, not a good example.

Please let me know then if you have any other technical concern that
requires this capability to be maintained separately for every lock.

So far, though, it seems like maintaining this capability separately
per lock is adding complexity, without it solving any technical
problem, that the simpler proposal doesn't solve as well.

If I'm missing anything please let me know,

Thanks,
Ohad.
--
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/