linux-kernel

Open Source and information security mailing list archives

Date:	Tue, 3 May 2011 15:45:03 +0100
From:	Dave Martin <dave.martin@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linaro-mm-sig@...ts.linaro.org, Valdis.Kletnieks@...edu,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] ARM DMA mapping TODO, v1

On Thu, Apr 28, 2011 at 02:12:40PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2011, Catalin Marinas wrote:
> > On Thu, 2011-04-28 at 01:15 +0100, Valdis.Kletnieks@...edu wrote:
> > > On Wed, 27 Apr 2011 12:08:28 BST, Catalin Marinas said:
> > > 
> > > > The current version of the ARM ARM says "unpredictable". But this
> > > > general definition of "unpredictable" does not allow it to deadlock
> > > > (hardware) or have security implications. It is however allowed to
> > > > corrupt data.
> > > 
> > > Not allowed to have security implications, but is allowed to corrupt data.
> > 
> > By security I was referring to TrustZone extensions. IOW, unpredictable
> > in normal (non-secure) world should not cause data corruption in the
> > secure world.
> 
> That definition is rather useless for operating systems that don't use
> Trustzone then, right?

IIUC, the restriction on unpredictable behaviour is basically that the processor
can't do anything which would result in or otherwise imply an escalation of
privilege.

TrustZone is one kind of privilege, but there are plenty of other operations
implying privilege (entering privileged mode from user mode, masking or
intercepting interrupts or exceptions, bypassing or reconfiguring MMU permissions
etc.)  "Unpredictable" behaviours are not allowed to have any such consequences
IIRC.  Without that restriction you wouldn't really have any OS security at all.

In the kernel, we do have to be careful about avoiding unpredictable behaviours,
since we're already running at maximum privilege (not including TZ) -- so the
damage which unpredictable behaviours can wreak is much greater, by running
invalid code, misconfiguring the MMU, allowing caches to get out of sync etc.
But that's not fundamentally different from the general need to avoid kernel bugs
-- the scope of _any_ kernel code to do damage is greater than for userspace code,
whether it involves architecturally unpredictable behaviour, or just plain
ordinary bugs or security holes in the C code.

---Dave

> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/

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