Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cve 2017 5715 2 #2055

Merged
merged 2 commits into from
Jan 16, 2018
Merged

Cve 2017 5715 2 #2055

merged 2 commits into from
Jan 16, 2018

Conversation

jenswi-linaro
Copy link
Contributor

@jenswi-linaro jenswi-linaro commented Jan 8, 2018

This pull request is done on top of #2048 to avoid unnecessary conflicts when finally merging everything. The commit to review here is core: arm32: thread: invalidate branch predictor.

Copy link
Contributor

@jforissier jforissier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With or without my comment addressed, and for "core: arm32: thread: invalidate branch predictor" only:
Reviewed-by: Jerome Forissier <[email protected]>

* The idea is to form a specific bit pattern in the lowest three
* bits of SP depending on which entry in the vector we enter via.
* This is done by adding 1 to SP in each entry but the last.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this deserves a few words to explain that the BPIALL has to be executed before any branch instruction is executed, hence the slightly convoluted code. I know I could/should have made the same comment for the sm commit ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor stuff: s/doesn't/does not/ , s/it's/it is/.

Sentence seems wrong to me: It doesn't matter if it's a conditional or an unconditional branch speculation can still occur..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it's a missing comma. How about:
It doesn't matter if it's a conditional or an unconditional branch, speculation can still occur.

@jforissier
Copy link
Contributor

What about 64-bits?

@jenswi-linaro
Copy link
Contributor Author

You're right I forgot about the 64-bit stuff. I'll add another patch here taking care of that.

@jenswi-linaro
Copy link
Contributor Author

Hmm, the 64-bit branch predictor invalidation is a bit more complicated. I'll take that in a separate pull request.

@jenswi-linaro
Copy link
Contributor Author

Commit updated, tag applied to core: arm32: thread: invalidate branch predictor only.

@@ -74,6 +77,11 @@
#define CFG_TEE_RAM_VA_SIZE CORE_MMU_PGDIR_SIZE
#endif

#ifdef CFG_WITH_LPAE
#define CORE_MMU_L1_TBL_OFFSET (CFG_TEE_CORE_NB_CORE * 4 * 8)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* 4 * 8 looks like magic, especially compared to how NUM_L1_ENTRIES is defined in core_mmu_lpae.c. Deserves a bit of explanation: why 4 64bit wide mmu descriptors ?

Regarding the armv7, the comment is straightforward: we need a full L1 table.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make these comments in #2048 instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, sorry.


v = (vaddr_t)thread_vect_table;
thread_user_kcode_va = ROUNDDOWN(v, CORE_MMU_USER_CODE_SIZE);
thread_user_kcode_size = CORE_MMU_USER_CODE_SIZE * 2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why 2 regions (likely pages)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make these comments in #2048 instead

@@ -748,6 +748,56 @@ END_FUNC thread_unwind_user_mode
FUNC thread_vect_table , :
UNWIND( .fnstart)
UNWIND( .cantunwind)
#ifdef CFG_CORE_WORKAROUND_SPECTRE_BP
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we shouldn't use a different config option here as we're protecting against a different attack and also the defense will be quite expensive in AArch64.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. CFG_CORE_WORKAROUND_SPECTRE_BP_SEC maybe? (rationale: still Spectre branch prediction attack but entirely within secure world hence _SEC).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good

@jenswi-linaro
Copy link
Contributor Author

Commit core: arm32: thread: invalidate branch predictor updated and rebased on top of #2048

@jforissier
Copy link
Contributor

Fine with me

@danh-arm
Copy link

danh-arm commented Jan 11, 2018

We've discovered that the BPIALL workaround is not effective in invalidating the branch predictor for Cortex-A15. An alternative workaround is described in the updated TF security advisory:

https://github.com/ARM-software/arm-trusted-firmware/wiki/Arm-Trusted-Firmware-Security-Advisory-TFV-6

That will affect your implementation here. Note we plan to push an example implementation of this in our SP_MIN payload in the coming days.

Also, it would be good if this workaround was not applied to unaffected CPUs (e.g. Cortex-A32, Cortex-A7 and Cortex-A5).

@jbech-linaro
Copy link
Contributor

We've discovered that the BPIALL ...
... That will affect your implementation here. Note we plan to push an example implementation of this in our SP_MIN payload in the coming days.

Thanks for letting us know Dan, this means it's worth for us wait a bit before merging this.

Also, it would be good if this workaround was not applied to unaffected CPUs (e.g. Cortex-A32, Cortex-A7 and Cortex-A5).

Agree!

@jforissier
Copy link
Contributor

Sounds like we may have to use runtime detection in order to install the proper exception vector. Otherwise, we can't properly support mixed configurations like big.LITTLE.

@etienne-lms
Copy link
Contributor

Can't we do something about it using the core/arch/arm/cpus/xxx.mk?
Current status is the patches are default enable but the platform can force their disabling.

@jenswi-linaro
Copy link
Contributor Author

Rebased on master, updated for runtime configuration.

Copy link
Contributor

@jforissier jforissier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the movs fixed:

Reviewed-by: Jerome Forissier <[email protected]>
Tested-by: Jerome Forissier <[email protected]> (HiKey)
Tested-by: Jerome Forissier <[email protected]> (HiKey960)

cmpne r2, r3
movne r3, #CORTEX_A75_PART_NUM
cmpne r2, r3
ldreq r0, =exception_vector_bpial
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/bpial/bpiall/

ldreq r0, =exception_vector_a15
beq 2f
#endif
1: ldr r0, =thread_vect_table
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor thing: now we have two wordings, "exception vector" and "thread vector table". I'd rather s/thread_vect_table/exception_vector/ but that's probably out of scope for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's take that cleanup in a later PR.

cmp_spsr_user_mode r0
bne 1f
/* Invalidate the branch predictor for the current processor. */
write_iciallu
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a note to emphasise that BPIALL doesn't fit here and ICIALLU is indeed required? I'm referring to the statement: "Note that the BPIALL instruction is not effective in invalidating the branch predictor on Cortex-A15. For that CPU, set ACTLR[0] to 1 during early processor initialisation, and invalidate the branch predictor by performing an ICIALLU instruction." from the Arm-TF page https://github.com/ARM-software/arm-trusted-firmware/wiki/Arm-Trusted-Firmware-Security-Advisory-TFV-6#variant-2-cve-2017-5715.

ubfx r2, r1, #MIDR_PRIMARY_PART_NUM_SHIFT, \
#MIDR_PRIMARY_PART_NUM_WIDTH

mov r3, #CORTEX_A8_PART_NUM
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core/arch/arm/kernel/thread_a32.S: Assembler messages:
core/arch/arm/kernel/thread_a32.S:477: Error: invalid constant (c08) after fixup
core/arch/arm/kernel/thread_a32.S:479: Error: invalid constant (c09) after fixup
core/arch/arm/kernel/thread_a32.S:481: Error: invalid constant (c0e) after fixup
core/arch/arm/kernel/thread_a32.S:483: Error: invalid constant (d07) after fixup
core/arch/arm/kernel/thread_a32.S:485: Error: invalid constant (d08) after fixup
core/arch/arm/kernel/thread_a32.S:487: Error: invalid constant (d09) after fixup
core/arch/arm/kernel/thread_a32.S:489: Error: invalid constant (d0a) after fixup
core/arch/arm/kernel/thread_a32.S:494: Error: invalid constant (c0f) after fixup

s/mov/movw/ and s/movne/movwne/ fixes the issues

@jenswi-linaro
Copy link
Contributor Author

Updated as requested, rebased, squashed and tags applied.

@jenswi-linaro
Copy link
Contributor Author

Pushed updates (commit message and a spell error in a comment) for two checkpatch warnings.
One checkpatch warning for a long line remains, I don't want to break the url.

@jenswi-linaro
Copy link
Contributor Author

Please wait with merging this, this PR requires ACTLR[0] set to 1 for Cortex-A15 platforms. I'm preparing another PR to take care of that.

@jforissier
Copy link
Contributor

@jenswi-linaro sure

@jenswi-linaro jenswi-linaro mentioned this pull request Jan 15, 2018
@jenswi-linaro
Copy link
Contributor Author

Needs #2071

With CFG_CORE_UNMAP_CORE_AT_EL0=y the exception vector is updated to use
the minimal kernel mapping during user space execution. With this patch
vbar is updated relative to previous value in vbar to allow different
exception vectors for different cpu types.

Reviewed-by: Jerome Forissier <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
If build with CFG_CORE_WORKAROUND_SPECTRE_BP_SEC=y invalidate branch
predictor on all secure world exceptions.

Fixes CVE-2017-5715

Tested-by: Jerome Forissier <[email protected]> (HiKey)
Tested-by: Jerome Forissier <[email protected]> (HiKey960)
Reviewed-by: Jerome Forissier <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
@jenswi-linaro
Copy link
Contributor Author

Rebased on master

@jforissier jforissier merged commit 4051194 into OP-TEE:master Jan 16, 2018
@jenswi-linaro jenswi-linaro deleted the cve-2017-5715-2 branch January 16, 2018 14:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants