Pseudo device id #1318

lws-team · 2017-01-26T05:17:11Z

These patches give OP-TEE the concept of a "Pseudo Device ID" that is passed in by the caller of OP-TEE. If the OP-TEE platform is configured to use it, then it becomes the "unique device ID" inside OP-TEE. As this is used to compute keys for "Secure Storage", that now becomes able to use per-device keys. TAs may also use the per-device ID using existing APIs for identity purposes.

When combined with a patch on arm-trusted-firmware[1], on Hikey a 32-bit unique ID is passed into OP-TEE, taken from the MMC CID serial number.

[1] See top patch on https://github.com/lws-team/arm-trusted-firmware/commits/pseudo-device-id

jforissier · 2017-01-26T09:06:46Z

Frankly I don't like the fact that you're changing the boot args. If you need to pass some data to OP-TEE, I think DT is the way to go. It may be time to revive my old PR: #679 (which is basically reading the DT to learn about the console UART). All the more since some DT stuff has been merged already (b908c67, 830a08e, 76358be, 834b346).

Another option would be to read the MMC CID directly from OP-TEE. That would require more code obviously, basically writing a basic MMC driver, but it may be seen as a first step towards native support of MMC which may be useful on its own right (using MMC for secure storage rollback protection, whatever the underlying FS? implementing the RPMB FS 100% inside the TEE so that it's available early, resistant to DOS attacks, more performant? just throwing out some ideas here).

Thoughts?

lws-team · 2017-01-26T09:21:03Z

Well, I can understand adding a boot arg is a surprising thing. It also has to add a register to BL2->BL31 boot args inside a-t-f, since BL2 that touches the eMMC is done by the time we start OP-TEE.

Basically you are saying how about either:

Pass more data from a-t-f

However, there's no DT passed to OP-TEE in Hikey case and starting to require that's a much bigger thing... it can still be more correct depending on what else you could leverage it for.

I added my own cut-down DTB editing code to a-t-f, since we talk about dynamic fdt content you are also requiring a-t-f to grow an fdt library. That's not necessarily a bad thing since it turns out a-t-f is very good at having a the Linux kernel + pieces as BL33 directly. But it is a much more major event.

Pass no data from a-t-f and grow an eMMC driver

If OP-TEE grows an eMMC driver, there's the issue of conflict and sync with Normal World, since the eMMC holds quite a bit of state like async completion of commands, that sounds like it will be painful. Read CID is an explicit command same as reading data, it must be synchronized inbetween pending commands in normal world if so.

If it grows an eMMC driver, it will grow filesystem drivers and pretty soon it's UEFI ^^

lws-team · 2017-01-26T09:31:26Z

Hm... about pass DTB... there is a DTB init arg in OP-TEE entry already.

If we want to go down that road without making a decision on everything else needing dtb, one way would be get started that a-t-f cooks a canned DTB stub with only one toplevel entry like /op-tee,device-id. Then on OP-TEE side, bring in the fdt library with the CFG_ that enables this feature, and use libfdt api to pick out the property.

Later if a-t-b + OP-TEE start using DTBs fully it's easy to migrate to using libfdt api on a-t-f too.

That gets rid of the extra OP-TEE init arg.

jforissier · 2017-01-26T09:36:47Z

Yep that was my thought exactly. Well while we're at it, we could define a DT entry that's likely to remain in the long run, such as /firmware/optee/device-id (we already have a DT binding for OP-TEE: https://lkml.org/lkml/2017/1/18/490).

lws-team · 2017-01-26T09:39:16Z

OK I'll study it later thanks.

jforissier · 2017-01-26T10:13:34Z

About potential conflicts between the kernel and the TEE MMC drivers: that's probably something that could be addressed by DT, since generic bindings exist for secure devices: d9f43babb998 ("Documentation: dt: Add bindings for Secure-only devices").

lws-team · 2017-01-26T11:53:55Z

There's only one eMMC on boards like Hikey... what you're talking about is assigning an SDHCI interface for secure-only... that is fine if your board is designed to do that and features a secure-only storage device on that interface.

Hikey et al have two or more SDHCI, but in terms of wire-up ones for storage one is the eMMC and one is the uSD card slot. It would probably be painful for many use-cases to have Normal World entirely locked out of the eMMC and only given the eMMC. Products wanting to do that would end up with two eMMC or all Normal World eMMC traffic proxied through Secure World.

vchong · 2017-01-26T12:23:22Z

also requiring a-t-f to grow an fdt library.

Just fyi, there is an fdt library in https://github.com/linaro-swg/arm-trusted-firmware/tree/optee_v2.1.0_paged_armtf_v1.2/lib/libfdt. The hikey branch (https://github.com/96boards-hikey/arm-trusted-firmware/tree/hikey/lib) is older and doesn't. Not sure how much work it would be to rebase onto a newer version.

HTH

jforissier · 2017-01-26T12:28:47Z

@lws-team OTOH, OP-TEE could grab the eMMC at init (before the kernel is booted), read the CID and never touch it again.

lws-team · 2017-01-26T12:36:46Z

@jforissier: the kernel isn't the only guy who grew an eMMC driver... UEFI and grub both do stuff in there, and a-t-f himself has an eMMC driver.

It seems OP-TEE init and Normal World init are unsynchronized if I understood it, BL32 is spawned then a-t-f is fetching or at least running BL33 which is often UEFI / Grub / U-Boot... all of whom touch eMMC as it stands.

lws-team · 2017-01-26T12:44:05Z

@vchong: thanks... personally I put my own fdt-walking and changing code in there, so I don't really need it. And the job here is making a tiny minimal fdt in a C array and poking things into it at a fixed offset.

I was hunting around again earlier for which tree my a-t-f came from originally... there are many old, dead trees and branches on github and elsewhere, and in the end I couldn't find it.

It's a reminder a-t-f has an upstream and at some point the only sane way is going to be to get the stuff Linaro has changed accepted there and the other trees archived somewhere. Or if they don't want hikey implementation, one golden fork. Which is to say big things like growing fdt shouldn't be one-time mouldering hacks in OOT repos but agreed with the upstream and implemented there.

jforissier · 2017-01-26T15:34:26Z

core/arch/arm/kernel/generic_boot.c

@@ -614,6 +614,7 @@ static void init_primary_helper(unsigned long pageable_part,

 	init_runtime(pageable_part);

+	IMSG("\n");


Please use IMSG_RAW("\n"); instead, to avoid the prefix.

And this is not the best place to put this, because init_runtime() does output some text already when CFG_WITH_PAGER=y. Since before init_runtime() is too early, you should add one IMSG_RAW("\n"); in init_runtime() before the message "Pager is enabled" (line 240), and another one at the end of the other version of init_runtime() (line 428).

lws-team · 2017-01-26T16:23:46Z

This is implemented as discussed, and working. I'll look at the cosmetic patch comment tomorrow.

The extra init param is removed. a-t-f now passes a canned DTB with the property "/firmware/optee/psuedo-device-id" fixed up to be the eMMC CID serial, and OP-TEE knows to pick out the property and use it if the platform is configured for it.

lws-team · 2017-01-27T01:55:37Z

The whole CFG_OTP thing is bogus... it provides static inlines even if not set, so we are always using it. I added a patch to change it to have a weak implementation and eliminated CFG_OTP + update the docs. Similarly we don't need any CFG_ to enable this now.

If platform override supplied for "OTP" apis, we only use that.
If no platform otp override the DTB and property came, we now use whatever came in the property, up to 160 bytes.
If no platform otp override, and DTB or no /firmware/optee-pseudo-device property, we do exactly as currently with 0 keys and BEEF ID.

jforissier

Looks good overall, please see my individual comments/questions.

jforissier · 2017-01-27T12:56:41Z

core/arch/arm/kernel/generic_boot.c

@@ -73,6 +73,9 @@
 */
 #define PADDR_INVALID		ULONG_MAX

+static uint8_t pseudo_device_id[160] __early_bss __attribute__ ((aligned (8)));


s/__attribute__ ((aligned (8)))/__aligned(8)/
Edit: BTW, why do we want a specific alignment?

At one point it was cast to uint32_t.... that went away before the last push. I removed it.

jforissier · 2017-01-27T13:01:04Z

core/arch/arm/kernel/generic_boot.c

+static void read_optee_pseudo_device_node(void *fdt)
+{
+	char s[33];
+	int offs, n = 0, m, len;


One variable per line please

jforissier · 2017-01-27T13:01:56Z

core/arch/arm/kernel/generic_boot.c

+	if (!p || !len)
+		return;
+
+	if (len > (int)sizeof(pseudo_device_id))


Is the cast needed?

Yeah.. len is forced to be an int by libfdt api. And it wants to do a comparison against unsigned (size_t) sizeof.

jforissier · 2017-01-27T13:12:03Z

core/arch/arm/kernel/generic_boot.c

+	memcpy(pseudo_device_id, p, len);
+	pseudo_device_id_len = len;
+
+	if (len > 16)


Several things I don't like here:

Truncation

Useless code when log level < INFO

Redundant use of __func__ (which is already taken care of by IMSG())

How about replacing all this (until the end of the function) with:

DMSG("Device ID read from DT:"); DHEXDUMP(pseudo_device_id, pseudo_device_id_len);

?
If you would really like to have it as "info", then it should be easy enough to add IHEXDUMP to lib/libutils/ext/include/trace.h.

I tried to follow this but it's a mess, DHEXDUMP doesn't quite do what you seem to think it does here. The end result is

INFO: TEE-CORE: secure-device-id: len 4: INFO: TEE-CORE: 000000003f039f28 08 35 d2 ac

ie, it starts a newline, looks like it dumps line number, function name, and insists to dump the VA of the start of the buffer.

What do you want to do... go back to old way protected by preprocessor check for INFO level OK? Or add like dump_raw()?

Both the truncation and the info is because I want to be able to confirm that users have unique serials without having a debug spew, and I don't need to dump 160 bytes each time to confirm that.

Hmmm, okay, fair enough, the output of DHEXDUMP is only good for debug really.
Let's do what you say, i.e., the old code guarded by a #if (TRACE_LEVEL >= TRACE_INFO)

jforissier · 2017-01-27T13:14:26Z

core/arch/arm/kernel/generic_boot.c

@@ -75,6 +75,7 @@

 static uint8_t pseudo_device_id[160] __early_bss __attribute__ ((aligned (8)));
 static size_t pseudo_device_id_len __early_bss;
+static const uint8_t default_pattern[4] = { 'B', 'E', 'E', 'F' };


Why move this out of tee_otp_get_die_id()? It's not referenced from anywhere else.

jforissier · 2017-01-27T13:17:27Z

core/arch/arm/kernel/generic_boot.c

+	}
+
+	for (n = 0; n < sizeof(hwkey->data); n++)
+		hwkey->data[n] = p[n % pseudo_device_id_len] ^ 0xff;


Is ^ 0xff useful?

I don't know. I thought it might be good if the "cpu id" and the hwkey data were not always identical. They are no treated as identical in the current case (hwkey is all 0 and "cpu id" is all beefy.

jforissier · 2017-01-27T13:29:39Z

core/arch/arm/plat-hikey/conf.mk

@@ -24,6 +24,8 @@ CFG_NUM_THREADS ?= 8
 CFG_CRYPTO_WITH_CE ?= y
 CFG_WITH_STACK_CANARIES ?= y

+$(call force,CFG_DT,y)


You definitely don't want to force this right now, otherwise people with an older ARM-TF (that does not pass a DT blob in r2) won't be able to boot.
So I think atm this should be a "documentation" patch, i.e., set CFG_DT ?= n and add a comment stating that HiKey can read a DT blob if available, stating the benefits (i.e., get a unique the device ID form the eMMC CID), and that one needs a proper ARM-TF for this (give a Git URL if possible).
Later, when the "official" ARM-TF for HiKey -- be it linaro-swg or higher up in the upstream hierarchy -- we can default to ?= y. And if some day we depend on DT features unconditionally, then we'll switch to force.

Yes... this patch was already intended as a "only use if you have patched a-t-f" patch... but that doesn't make sense for upstream series... I changed it to your scheme with docs and here set CFG_DT in the parent level makefile.

jforissier · 2017-01-27T13:44:18Z

core/arch/arm/kernel/generic_boot.c

+	if (offs < 0)
+		return;
+
+	p = fdt_getprop(fdt, offs, "pseudo-device-id", &len);


I'd rather drop the "pseudo-`. IMO it adds no value.

Since it's a node that is read by secure world only, we may want to add the "secure-" prefix. Again I'm refering to this kernel commit: d9f43ba ("Documentation: dt: Add bindings for Secure-only devices")

I'd like this binding to be documented somewhere. That's actually a general question for all subnodes of /firmware/optee: where should they be documented? I'd say: data consumed by non-secure world should be documented with the kernel bindings, and the secure ones should go somewhere in optee_os/documentation. Thoughts?

There's a typo in your commit message ('psuedo').

I globally renamed everything "secure-device-id" including the property.

I added a new doc file explaining the secure-only scope of the docs and that everything is inside firmware { optee } }, and documenting the new property.

lws-team · 2017-01-27T16:02:33Z

It's updated as discussed... I just repushed with fixes for travis that it hasn't gotten to yet.

The arm-trusted-firmware tree is updated to match.

lws-team · 2017-01-28T00:56:58Z

Well, sunxi doesn't bring in generic_boot.c. I added an "otp-stubs.c" in the patch that converts away from OTP and put the weak stubs in there, and had it built for all cases. That should finally satisfy travis.

jforissier

A few more comments...

@jenswi-linaro any comments or concerns with this approach?

jforissier · 2017-01-30T08:54:58Z

core/arch/arm/kernel/otp-stubs.c

+#include <util.h>
+#include <stdio.h>
+
+#include <platform_config.h>


Not all includes are needed

Yep... whittled it down.

jforissier · 2017-01-30T08:56:25Z

core/arch/arm/kernel/sub.mk

@@ -2,6 +2,7 @@ srcs-$(CFG_WITH_USER_TA) += user_ta.c
 srcs-y += static_ta.c
 srcs-y += elf_load.c
 srcs-y += tee_time.c
+srcs-y += otp-stubs.c


otp_stubs.c (underscore, not hyphen).
[Me too I tend to prefer with a hyphen, but let's be consistent]

OK it's changed.

jforissier · 2017-01-30T09:10:33Z

core/arch/arm/kernel/generic_boot.c

+
+	IMSG("secure-device-id: len %d: %s\n",
+	     (int)secure_device_id_len, s);
+#endif


Please use a helper function (easier to read):

#if (TRACE_LEVEL >= TRACE_INFO) static void print_device_id() { int len = secure_device_id_len; char s[33]; int n = 0; int m; if (len > 16) len = 16; for (m = 0; m < len; m++) n += snprintf(&s[n], sizeof(s) - n - 1, "%02X", secure_device_id[m]); IMSG("secure-device-id: len %d: %s\n", (int)secure_device_id_len, s); } #else static void print_device_id() {} #endif

I just removed it... my TA now consumes this via a "property" and gets the generic die id as a UUID; I report that in my TA.

However there seems no way in OP-TEE to format and dump the UUID type as a string... if I didn't simply miss it do you want one?

Inside OP-TEE there is %pUl that you can use with snprintf() and DMSG() and friends (this syntax was taken from the Linux kernel). When I added this format, I decided not to make it available to TAs, to avoid breaking the standard. Now I'm not sure it was a good choice...

For something that's all about UUIDs it's a curious omission. As I say the device's definitive identity comes out as a UUID by design, real TAs are going to want to log it or in my case append to a URL.

jforissier · 2017-01-30T09:13:56Z

core/arch/arm/kernel/generic_boot.c

+
+	memcpy(secure_device_id, p, len);
+	secure_device_id_len = len;
+


Here I think you should scrub the secure-devide-id node in the DT. Because you probably don't want to leak this information to the NS world (I'm assuming the ID is read by ARM-TF from a protected area -- which is not the case if ID is the eMMC CID of course, but I'm thinking more generally).

There's no path for Normal World to read the DTB from OP-TEE atm. Indeed we feed it a stub DTB from a-t-f that goes nowhere and has no way to go anywhere else.

Indeed what exists at the minute is a pattern of a-t-f starting both OP-TEE and the Normal World OS, each with their own DTB if they want it, so there is no need for this. Or do I miss the point?

You miss the point ;) Well, not entirely obviously. At the moment, there is nothing wrong with having two DTs, one for secure world and the other one for normal world. But, I think it should be our goal to try and unite them. That's also the direction taken by Peter Maydell in his kernel patch (introducing the secure- prefix). Therefore I'd rather have OP-TEE assume that the DT might be shared with the kernel, so if there is some information inside, that is for OP-TEE to consume and that should not leak to NW, then OP-TEE had better clear it.

Thoughts?

It seems I did get your point... but you want to wipe all secure- guys IIUI.

This is the make clean thing again... if you want to do that nicely, you should have a node containing them and delete the node.

However this patch isn't about "all secure- properties". The guy who adds the patch that hands this DTB on to NS world....(eh... it makes no sense to me... a-t-f gave the DTB to OP-TEE and then OP-TEE will give it back to a-t-f to give to Normal World? That is not how it works atm... anyway...).

If out of consideration for this happy moment in the future, you want to move secure-device-id under a sacrificial, make-clean-style node, that'd make sense and I can adapt it.

Trying to get every user to clean his node though ends up with nodes with no current user in OP-TEE being left in etc... it's a pretty exact rerun of make clean... this isn't otherwise my problem I think...

jforissier · 2017-01-30T09:15:59Z

core/include/kernel/tee_common_otp.h

@@ -39,4 +39,7 @@ struct tee_hw_unique_key {
 void tee_otp_get_hw_unique_key(struct tee_hw_unique_key *hwkey);
 int tee_otp_get_die_id(uint8_t *buffer, size_t len);

+extern uint8_t secure_device_id[160] __early_bss;
+extern size_t secure_device_id_len __early_bss;


I don't think the __early_bss qualifiers are needed here.

jforissier · 2017-01-30T09:29:44Z

documentation/dt-bindings.md

+
+This may produce less data than a real key on the SoC,
+but it is still very useful since it requires no
+configuration to get a unique number.


The problem with the eMMC CID is that it may be read from NS world too, which does not make it very good source of data to derive security keys... I do agree that it's convenient, so it's probably a valid example for some use cases, but I think you should state clearly that doing so is not much more secure than hard-coding a security key in the clear text binary.
Of course the bootloader may have access to other sources of private data, which really justifies this secure-device-id mechanism.

Mmm that is not what is going on with this, that is also why it was called a "pseudo device ID" in the first patches.

This isn't trying to "be" the device key e-fuses, it's trying to solve the existing situation that for OP-TEE there is zero logical difference between any number of same boards like Hikey.

That directly leads to really undesirable situations in OP-TEE itself like Secure Storage is not secure at all. And real applications in the TA also need this, for example tracking of unprovisioned devices to get the assigned key data in the factory, or to recover them if they need it in the field.

While this number belongs to the eMMC and not the SoC, and while it is only 32-bits, in every other way it is real, usable device-specific key data that needs no configuration.

not much more secure than hard-coding a security key in the clear text binary

This data comes out of the board at runtime, so it doesn't need unique TA binaries per device.

Yes it's not secure in itself at all... it's not fighting e-fuses it's fighting every board is 100% the same to OP-TEE when OP-TEE's business involves per-device crypto and defeating copying secure storage content between individual devices.

I will send another documentation patch in the next weeks addressing this big missing section at the start of the docs listing the steps you have to take to make OP-TEE secure, we can mention this there.

jenswi-linaro

The approach is good.
Please rephrase the commit message "dtb: no need to freak out if we were given a dtb with expected nodes".

jenswi-linaro · 2017-01-30T09:43:41Z

core/arch/arm/kernel/generic_boot.c

+
+	IMSG("secure-device-id: len %d: %s\n",
+	     (int)secure_device_id_len, s);
+#endif


jenswi-linaro · 2017-01-30T09:48:30Z

core/arch/arm/kernel/otp-stubs.c

+
+#include <platform_config.h>
+
+uint8_t secure_device_id[160] __early_bss;


__early_bss not needed

160 should be defined instead

jenswi-linaro · 2017-01-30T09:50:10Z

core/arch/arm/kernel/otp-stubs.c

+
+__weak void tee_otp_get_hw_unique_key(struct tee_hw_unique_key *hwkey)
+{
+	const uint8_t *p = (uint8_t *)&secure_device_id;


Assigning just secure_device_id without casting should be enough

Yeah... it went through a form where it was a uint32 *. Now no problem as you say.

jenswi-linaro · 2017-01-30T09:52:29Z

core/arch/arm/kernel/otp-stubs.c

+	size_t n;
+
+	if (!secure_device_id_len) {
+		memset(&hwkey->data[0], 0, sizeof(hwkey->data));


Please use just hwkey->data

jenswi-linaro · 2017-01-30T09:59:00Z

core/arch/arm/kernel/otp-stubs.c

+
+__weak int tee_otp_get_die_id(uint8_t *buffer, size_t len)
+{
+	static const uint8_t default_pattern[4] = { 'B', 'E', 'E', 'F' };


The 4 in [4] is redundant.
An alternative to the approach in this function is to have secure_device_id initialized at compile time.

Not my code ;-) just cut and pasted. And advice on this PR was already to move it into function scope out of filescope where I originally moved it. So just getting rid of the 4.

Otherwise at least on Hikey, it comes partway through an a-t-f message and is hard to parse. Placement modified after comments by jforissier Signed-off-by: Andy Green <andy@warmcat.com>

…ected nodes Signed-off-by: Andy Green <andy@warmcat.com>

There is no longer any point in having CFG_OTP_SUPPORT. It's always supported either by the weak implementation or any platform override. Since there exists a platform 'sunxi' that does not have CFG_GENERIC_BOOT and doesn't build generic_boot.c, this is plaved in a new file 'otp_stubs.c'. Since this is just copied Linaro code at this point, keep Linaro copyright message on the new file. Signed-off-by: Andy Green <andy@warmcat.com>

If a DTB came in, grab /firmware/optee/secure-device-id from it if present. Signed-off-by: Andy Green <andy@warmcat.com>

Make the default device ID handlers use the secure-device-id if it was passed in by DTB. Whatever length the property has in the DTB is used for the secure device id, up to the maximum of 160 bytes. If the available secure id is too small, it is repeated up to the required length. Signed-off-by: Andy Green <andy@warmcat.com>

Patches exist on a-t-f to make it provide a secure device ID via DTB when it starts OP-TEE. If you are using the patched a-t-f, you can enable DT support for hikey to have the secure device ID used automatically in OP-TEE. This patch explains the situation in the config, keeping the default to off. Signed-off-by: Andy Green <andy@warmcat.com>

Signed-off-by: Andy Green <andy@warmcat.com>

jforissier · 2017-02-27T07:32:51Z

documentation/dt-bindings.md

+
+OP-TEE may also be passed a DTB at boot-time, which
+may be different to, or modified from, the DTB passed
+to Normal World.


No. Commit 76358be ("core: arm: generic boot: edit device tree") assumes that modifications made by OP-TEE to the DT will be visible to the kernel. So, for all practical purpose, one should consider that there is only one DT, which might be modified by OP-TEE before it is passed to the NW kernel. Although the actual implementation might be different (for instance the firmware might make copy the DT between secure and non-secure memory).

lws-team · 2017-02-27T08:01:28Z

Okie, so since you are saying OP-TEE remit extends to deciding how a-t-f boots the kernel, how does it work that a-t-f fished out the OP-TEE modifications to the DTB and gives it to the kernel?

There are many boot scenarios for ARM64, by volume UEFI is not the number one guy. In our case we boot directly from a-t-f. So there is some docs somewhere I should have read in Janurary about this patch from July that explains to me how to do it consistent with the OP-TEE view of the One True Way?

jforissier · 2017-04-21T16:21:55Z

FYI, I've picked up and merged the first three patches which are good and are helpful to simplify another PR.

I am OK with the remaining ones, except I feel a bit uncomfortable about dt-bindings.md, I mean it's not clear what to expect as a DT (describes secure world only? secure and normal worlds? can it be modified and passed on to normal world?). We're actually making this dependent on the platform/use case, which might or might not be a good move. Or maybe it is (in which case your documentation is fine).

@jenswi-linaro @jbech-linaro @etienne-lms any objection to merging this?

jenswi-linaro · 2017-04-25T08:11:28Z

From an OP-TEE OS point of veiw, wouldn't this typically belong somewhere in /secure-chosen since it is a boot argument?

github-actions · 2020-01-12T00:17:20Z

This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed pull request at any time.

lws-team force-pushed the pseudo-device-id branch from 549b0ee to 5446515 Compare January 26, 2017 05:52

lws-team mentioned this pull request Jan 26, 2017

API for reading 'efuse' values if platform supports them #1294

Closed

jforissier reviewed Jan 26, 2017

View reviewed changes

lws-team force-pushed the pseudo-device-id branch from 5446515 to 4f88695 Compare January 26, 2017 16:18

lws-team force-pushed the pseudo-device-id branch from 4f88695 to 9468ab8 Compare January 27, 2017 01:48

jforissier reviewed Jan 27, 2017

View reviewed changes

lws-team force-pushed the pseudo-device-id branch 2 times, most recently from d3c9b31 to 5e0c2aa Compare January 27, 2017 16:01

lws-team force-pushed the pseudo-device-id branch from 5e0c2aa to 528e7c5 Compare January 28, 2017 00:45

jforissier reviewed Jan 30, 2017

View reviewed changes

jenswi-linaro reviewed Jan 30, 2017

View reviewed changes

lws-team added 4 commits January 30, 2017 20:53

Add one IMSG line before OP-TEE init message

fac249d

Otherwise at least on Hikey, it comes partway through an a-t-f message and is hard to parse. Placement modified after comments by jforissier Signed-off-by: Andy Green <andy@warmcat.com>

dtb: no need to print trace with an ! if we were given a dtb with exp…

6841e18

…ected nodes Signed-off-by: Andy Green <andy@warmcat.com>

secure-device-id: add /firmware/optee/secure-device-id to DTB parsing

4887700

If a DTB came in, grab /firmware/optee/secure-device-id from it if present. Signed-off-by: Andy Green <andy@warmcat.com>

lws-team added 3 commits January 30, 2017 20:53

dt: document secure-device-id binding

65b0367

Signed-off-by: Andy Green <andy@warmcat.com>

lws-team force-pushed the pseudo-device-id branch from 528e7c5 to 65b0367 Compare January 30, 2017 12:54

jforissier reviewed Feb 27, 2017

View reviewed changes

jforissier mentioned this pull request Apr 21, 2017

Add OTP hardware key support to plat-ti #1492

Merged

github-actions bot added the Stale label Jan 12, 2020

github-actions bot closed this Jan 21, 2020

		@@ -614,6 +614,7 @@ static void init_primary_helper(unsigned long pageable_part,

		init_runtime(pageable_part);

		IMSG("\n");


		memcpy(secure_device_id, p, len);
		secure_device_id_len = len;


		#include <platform_config.h>

		uint8_t secure_device_id[160] __early_bss;

Pseudo device id #1318

Pseudo device id #1318

Conversation

lws-team commented Jan 26, 2017

jforissier commented Jan 26, 2017

lws-team commented Jan 26, 2017

lws-team commented Jan 26, 2017

jforissier commented Jan 26, 2017

lws-team commented Jan 26, 2017

jforissier commented Jan 26, 2017

lws-team commented Jan 26, 2017

vchong commented Jan 26, 2017

jforissier commented Jan 26, 2017

lws-team commented Jan 26, 2017

lws-team commented Jan 26, 2017

Choose a reason for hiding this comment

lws-team commented Jan 26, 2017

lws-team commented Jan 27, 2017

jforissier left a comment

Choose a reason for hiding this comment

jforissier Jan 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lws-team commented Jan 27, 2017

lws-team commented Jan 28, 2017

jforissier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jenswi-linaro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lws-team commented Feb 27, 2017

jforissier commented Apr 21, 2017

jenswi-linaro commented Apr 25, 2017

github-actions bot commented Jan 12, 2020

jforissier Jan 27, 2017 •

edited

Loading