linux-kernel - Re: [PATCH v6 2/2] hwspinlock: qcom: Add support for Qualcomm HW Mutex block

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]

Message-ID: <20150318161057.GY26334@sonymobile.com>
Date:	Wed, 18 Mar 2015 09:10:57 -0700
From:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
To:	Lina Iyer <lina.iyer@...aro.org>
CC:	Andy Gross <agross@...eaurora.org>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Jeffrey Hugo <jhugo@...eaurora.org>,
	Suman Anna <s-anna@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 2/2] hwspinlock: qcom: Add support for Qualcomm HW
 Mutex block

On Thu 12 Mar 12:55 PDT 2015, Lina Iyer wrote:

> On Thu, Mar 12 2015 at 13:43 -0600, Andy Gross wrote:
> >On Thu, Mar 12, 2015 at 01:31:50PM -0600, Lina Iyer wrote:
> >> On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote:
[..]
> >> Also, talking to Jeff it seems like that out of the 32 locks defined
> >> only 8 is accessible from Linux. So its unnecessary and probably
> >> incorrect to assume that there are 32 locks available.
> >
> >Out of curiosity, this is a TZ thing?  If so, we'd expect issues if someone
> >decides to utilize resources that, while technically are present, are unusable
> >by that processor.  This is not that much different from someone misconfiguring
> >an EE on a DMA controller.
> >
> Per Jeff, the protection unit doesnt generally allow access to locks > 8
> and shouldnt be allowed and in some SoC's where they dont have the
> protection, it might still be a bad idea. It would be safer to restrict to
> 8, than allow all 32 and hope somebody doesnt do the wrong thing.
> 

You have the same problem with all peripherals that are shared between
the various subsystems; e.g. the BLSPs used by the sensor DSP shouldn't
be touched by the Linux system.

But what if Linux runs on the sensor DSP?


The driver should support the hardware and the system configuration (DT)
should make sure the valid resources are accessed.

Regards,
Bjorn
--
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/