linux-kernel - Re: [PATCH v5 1/5] ARM: add basic Trusted Foundations support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Sep 2013 11:18:09 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Will Deacon <will.deacon@....com>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Rob Herring <robherring2@...il.com>,
	Mark Rutland <Mark.Rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Kevin Hilman <khilman@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Stephen Warren <swarren@...dotorg.org>,
	Tomasz Figa <t.figa@...sung.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	Olof Johansson <olof@...om.net>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 1/5] ARM: add basic Trusted Foundations support

On Tue, Sep 10, 2013 at 3:04 PM, Will Deacon <will.deacon@....com> wrote:
> On Mon, Sep 09, 2013 at 07:15:31AM +0100, Alexandre Courbot wrote:

>> I don't have any information about the future of TF unfortunately,
>> excepted that it should remain backward-compatible. What is this SMC
>> calling convention doc your are talking about btw? Is there a standard
>> calling convention defined by ARM?
>
> SMC calling convention:
> https://silver.arm.com/download/download.tm?pv=1435186

According to the SMC calling convention r0 should be
the SMC function identifier.

+static void __naked tf_generic_smc(u32 type, u32 subtype, u32 arg)
+{
+       asm volatile(
+               ".arch_extension        sec\n\t"
+               "stmfd  sp!, {r4 - r11, lr}\n\t"
+               __asmeq("%0", "r0")
+               __asmeq("%1", "r1")
+               __asmeq("%2", "r2")
+               "mov    r3, #0\n\t"
+               "mov    r4, #0\n\t"
+               "smc    #0\n\t"
+               "ldmfd  sp!, {r4 - r11, pc}"
+               :
+               : "r" (type), "r" (subtype), "r" (arg)
+               : "memory");
+}

So type == function identifier? Or are these two totally
different things, such that trusted foundations are already
a different beast that what the SMC calling convention
specifies?

Anyway:
r0,r1,r2 = type/subtype/arg.

+#define TF_SET_CPU_BOOT_ADDR_SMC 0xfffff200
(...)
+static int tf_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
+{
+       tf_generic_smc(TF_SET_CPU_BOOT_ADDR_SMC, boot_addr, 0);
+
+       return 0;
+}

What kind of a "subtype" is the boot address? I could have
accepted it if the *last* thing, the argument contained the boot
address. With the type/subtype/arg convention it would be
more natural if the "subtype" was something like 0.

Should the SMC function rather have this signature:

tf_generic_smc(u32 type, u32 arg1, u32 arg2)

?

Then *sometimes* arg1 is a subtype, if the "type" is
such that it takes a subtype?

(That's a rough guess.)

So to begin with the arguments to tf_generic_smc() are either
confusingly named or tf_set_cpu_boot_addr() begins the
journey with violating the function signature.

I also wonder what kind if "type" starts its enumerator on
0xfffff200? Wouldn't it be more natural if it was e.g. 1?
It looks like the TF_SET_CPU_BOOT_ADDR_SMC
reflects some bit-wise encoding scheme, so some details
here wouldn't hurt?

The main thing is that the patch has to say that this
is an API toward trusted foundations, that it has nothing
to do with the SMC calling conventions, and only pertain
to devices that use trusted foundations, so as to avoid
any confusion.

Then I'm game :-)

Yours,
Linus Walleij
--
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/