X86 security extensions #24

jonwoodruff · 2023-01-04T10:33:37Z

This is a new section to compare with recent x86 security extensions. Some extensions may be missing, and bits of these sections may be missing as well.

bsdjhb

This generally seems fine to me. I had thought that the ENDBRANCH part of CET was a subset of what sentries provide (such that you could dispense with that part of CET if desired). In particular, IIRC CET has some somewhat convoluted ways to handle exceptions (branches that should still be allowed without using ENDBRANCH), and that the management of sentries gives an easier way to permit policy around which branches are protected.

Related to this last is that it may make sense (we should at least add a rationale note?) to have a way to require branches to use sentries, at least for user mode (e.g. via a bit in CR4 that supervisor mode could set).

bsdjhb · 2023-03-09T21:53:21Z

Oh, it would probably be good to collapse the history of this branch down and use git rebase (instead of git merge) to simplify the history.

jrtc27 · 2023-03-09T22:09:13Z

Requiring branch targets to always be sentries would add a pointless instruction for jump tables; the current lowering for CHERI-RISC-V and Morello translated to CHERI-X86-64 (assuming code model with max 2 GiB code) would be something like:

foo:
.Lfoo$jump_table_base:
	...
	leac	.LJTIm_n(%cip), %ctable
	movslq	(%ctable,%rindex,4), %roffset
	leac	.Lfoo$jump_table_base(%cip), %ctarget
	addc	%roffset, %ctarget
	jmpc	*%ctarget

Requiring sentries would put a csealentry %ctarget in between the last two instruction which just bloats things.

jrtc27 · 2023-03-09T22:25:45Z

Although doing leac .LJTIm_n(%cip), %ctable rather than movc .LJTIm_n@GOTPCREL(%cip), %ctable is a bit dodgy actually, if there are cases the compiler believes are impossible but end up happening, which one can easily construct... then you get an untrapped OOB read that is then used as an offset to jump to. Should fix CHERI-RISC-V and Morello to be more conservative...

brooksdavis · 2023-04-04T16:23:04Z

This PR would benefit from rebasing.

bsdjhb · 2023-08-03T23:20:22Z

chap-cheri-x86-64.tex

 If the \insnxesref{XCHG} instructions \texttt{91} - \texttt{97} are not
 commonly used, they could be removed in capability mode.
+
+\section{Relationship to x86 Security Extensions}


Add "Existing" before x86 perhaps?

bsdjhb · 2023-08-03T23:26:21Z

chap-cheri-x86-64.tex

+presumably enabled for both consumer and professional variants.
+
+In userspace, a thread may write its PKRU register, which maps
+16 pairs of read/write permissions coorosponding to the 16 possible


Suggested change

16 pairs of read/write permissions coorosponding to the 16 possible

16 pairs of read/write permissions corresponding to the 16 possible

bsdjhb · 2023-08-03T23:26:40Z

chap-cheri-x86-64.tex

+By writing this register, a thread may quickly remove access to subsets
+of pages.
+Current implementations appear to flush the back end of the pipeline,
+incuring a cycle penalty of roughly 20 cycles.


Suggested change

incuring a cycle penalty of roughly 20 cycles.

incurring a cycle penalty of roughly 20 cycles.

bsdjhb · 2023-08-03T23:26:53Z

chap-cheri-x86-64.tex

+of pages.
+Current implementations appear to flush the back end of the pipeline,
+incuring a cycle penalty of roughly 20 cycles.
+This filtering is naturally per-thread, unlike the page table iteself


Suggested change

This filtering is naturally per-thread, unlike the page table iteself

This filtering is naturally per-thread, unlike the page table itself

bsdjhb · 2023-08-03T23:27:27Z

chap-cheri-x86-64.tex

+
+While MPK appears to be extremely unscalable on the surface, work
+has been done to virtualise the page sets with an API similar to
+memprotect so that sets of pages can have their access permissions


Suggested change

memprotect so that sets of pages can have their access permissions

mprotect so that sets of pages can have their access permissions

Not sure if you intend a specific memprotect() function distinct from the POSIX mprotect()? If so, this might need a citation?

bsdjhb · 2023-08-03T23:31:39Z

chap-cheri-x86-64.tex

+As a result, MPX "failed open" in many cases where unexpected
+cases arose.
+If the pointer from the bounds table did not match the pointer
+from memory, bounds were left in state that would not fault.


Suggested change

from memory, bounds were left in state that would not fault.

from memory, bounds were left in a state that would not fault.

bsdjhb · 2023-08-03T23:34:54Z

chap-cheri-x86-64.tex

+CHERI relies on simple invariants that can be enforced within
+single-cycle instructions.
+Intel SGX instead trusts the correctness and atomicity of
+hyper-visor-like subroutine calls due to their being


Suggested change

hyper-visor-like subroutine calls due to their being

hypervisor-like subroutine calls due to their being

bsdjhb · 2023-08-03T23:35:21Z

chap-cheri-x86-64.tex

+hyper-visor-like subroutine calls due to their being
+provided by processor firmware.
+
+On one hand, the SGX precedent suggests that trusted hyper-visor-like


Suggested change

On one hand, the SGX precedent suggests that trusted hyper-visor-like

On one hand, the SGX precedent suggests that trusted hypervisor-like

bsdjhb · 2023-08-03T23:44:24Z

chap-cheri-x86-64.tex

+or branch prediction can easily push overheads over 20\% and
+greatly restrict adoption.
+
+\subsection{Intel SGX (deprecated)}


I don't think SGX is deprecated fully (unlike MPX). Intel has dropped it from "consumer" CPUs, but Xeons still ship it I believe according to https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141

bsdjhb · 2023-08-03T23:48:38Z

chap-cheri-x86-64.tex

+
+On one hand, the SGX precedent suggests that trusted hyper-visor-like
+subroutines can be implemented in the CPU.
+On the other hand, Intel SGX was only implemented in a single Intel


I'm not sure these next two sentences are accurate. Intel's current top-of-line Xeon processors ship SGX: https://www.intel.com/content/www/us/en/products/details/processors/xeon/scalable/platinum.html

jonwoodruff requested a review from bsdjhb January 4, 2023 10:33

bsdjhb reviewed Mar 9, 2023

View reviewed changes

jonwoodruff and others added 10 commits July 26, 2023 11:10

A start on an extensions section.

69ebba2

A bit of an update for the security extensions section.

d192ce0

The beginning of a section on the memory encryption technologies.

306f381

Add a synergy section.

8a92578

Add a section on MPX, as well as fix a few typos.

7089e48

A few spell fixes and a bit of editing of the MPX section.

56d4fa5

Some fixes to TME. It's shipped!

40f3455

Add section on SGX.

2a20b7d

Add a section on Memory Protection Keys (MPK).

c704b4c

Whitespace fixes and a note in the 9.0 appendix.

c4c9757

bsdjhb force-pushed the x86_security_extensions branch from f10349e to c4c9757 Compare July 27, 2023 15:50

bsdjhb reviewed Aug 3, 2023

View reviewed changes

Add reference to speculation contracts paper.

ac268bf

	16 pairs of read/write permissions coorosponding to the 16 possible
	16 pairs of read/write permissions corresponding to the 16 possible

	incuring a cycle penalty of roughly 20 cycles.
	incurring a cycle penalty of roughly 20 cycles.

	This filtering is naturally per-thread, unlike the page table iteself
	This filtering is naturally per-thread, unlike the page table itself

	memprotect so that sets of pages can have their access permissions
	mprotect so that sets of pages can have their access permissions

	from memory, bounds were left in state that would not fault.
	from memory, bounds were left in a state that would not fault.

	hyper-visor-like subroutine calls due to their being
	hypervisor-like subroutine calls due to their being

	On one hand, the SGX precedent suggests that trusted hyper-visor-like
	On one hand, the SGX precedent suggests that trusted hypervisor-like

X86 security extensions #24

Are you sure you want to change the base?

X86 security extensions #24

Uh oh!

Conversation

jonwoodruff commented Jan 4, 2023

Uh oh!

bsdjhb left a comment

Choose a reason for hiding this comment

Uh oh!

bsdjhb commented Mar 9, 2023

Uh oh!

jrtc27 commented Mar 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrtc27 commented Mar 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brooksdavis commented Apr 4, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jrtc27 commented Mar 9, 2023 •

edited

Loading

jrtc27 commented Mar 9, 2023 •

edited

Loading