Bug 179282 - [amd64] [patch] add Intel SMAP for FreeBSD-CURRENT
Summary: [amd64] [patch] add Intel SMAP for FreeBSD-CURRENT
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: amd64 (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-amd64 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-04 00:10 UTC by Oliver Pinter
Modified: 2019-08-29 15:21 UTC (History)
8 users (show)

See Also:

Attachments
file.txt (18.63 KB, patch)
2013-06-04 00:10 UTC, Oliver Pinter 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Pinter 2013-06-04 00:10:01 UTC 
As subpart of my thesis, I implemented Intel SMAP[1] support for FreeBSD.
The current stable version of patch (attached) have compile time
option to enable SMAP.*

A feature complete dynamic version is expected by the end of the
month, which patched the kernel on boot time, when the feautre
presented in CPU.

[1] http://lwn.net/Articles/517475/

patches: https://github.com/opntr/freebsd-patches-2013-tavasz
smap-test: https://github.com/opntr/freebsd-smap-tester

Fix: Patch attached with submission follows:
Comment 1 Oliver Pinter 2014-05-05 12:11:10 UTC 
I'm working on this, as part of FreeBSD GSoC2014.

On 6/4/13, FreeBSD-gnats-submit@freebsd.org
<FreeBSD-gnats-submit@freebsd.org> wrote:
> Thank you very much for your problem report.
> It has the internal identification `amd64/179282'.
> The individual assigned to look at your
> report is: freebsd-amd64.
>
> You can access the state of your problem report at any time
> via this link:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=179282
>
>>Category:       amd64
>>Responsible:    freebsd-amd64
>>Synopsis:       [PATCH] Intel SMAP for FreeBSD-CURRENT
>>Arrival-Date:   Mon Jun 03 23:10:01 UTC 2013
>
Comment 2 Sean Bruno freebsd_committer freebsd_triage 2015-07-01 17:36:17 UTC 
Oliver:

Did you shovel this into phabricator at any point?  I think you did no?
Comment 3 Oliver Pinter freebsd_committer freebsd_triage 2015-07-04 01:20:57 UTC 
This patch needs an update after the x86 refactors. I will do in the next few weeks.
Comment 4 op 2017-11-04 21:39:25 UTC 
This patch is now outdated and needs updating.
I have an internal version for 10-STABLE. It fixed a missing thing, which would lead to security issues. So DO NOT COMMIT this version of the patch.
Comment 5 op 2017-11-04 21:51:00 UTC 
And this is the fix for the security issue:

diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 12166b785508..ae31a9d0e896 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1680,7 +1680,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
        msr = ((u_int64_t)GSEL(GCODE_SEL, SEL_KPL) << 32) |
              ((u_int64_t)GSEL(GUCODE32_SEL, SEL_UPL) << 48);
        wrmsr(MSR_STAR, msr);
-       wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D);
+       wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D|PSL_AC);
 
        /*
         * Temporary forge some valid pointer to PCB, for exception
Comment 6 Konstantin Belousov freebsd_committer freebsd_triage 2017-11-05 13:16:13 UTC 
Do not commit this.

The right aprroach is to use ifunc to override the implementation of MD functions.  We are very close to have the static linkers which support the feature, and then I will commit my patch to use ifuncs, in particular, for SLAC variants of copyin/out.
Comment 7 op 2017-11-05 18:47:13 UTC 
@kib: have you tested your version with bhyve? Your guest are bootable in them with SMAP?
Comment 8 Ed Maste freebsd_committer freebsd_triage 2018-07-31 20:36:17 UTC 
ifunc implementation committed in r336876
Comment 9 Mark Johnston freebsd_committer freebsd_triage 2019-08-29 15:21:52 UTC 
A different implementation of SMAP support was committed in r336876.