Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1589695 > unrolled thread
| Started by | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| First post | 2017-02-28 19:50 +0100 |
| Last post | 2017-03-07 17:50 +0100 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH v6 0/4] Application Data Integrity feature introduced by SPARC M7 Khalid Aziz <khalid.aziz@oracle.com> - 2017-02-28 19:50 +0100
Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) Anthony Yznaga <anthony.yznaga@oracle.com> - 2017-03-07 01:30 +0100
Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) Khalid Aziz <khalid.aziz@oracle.com> - 2017-03-07 01:40 +0100
Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) Anthony Yznaga <anthony.yznaga@oracle.com> - 2017-03-07 02:30 +0100
Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) Khalid Aziz <khalid.aziz@oracle.com> - 2017-03-07 17:50 +0100
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2017-02-28 19:50 +0100 |
| Subject | [PATCH v6 0/4] Application Data Integrity feature introduced by SPARC M7 |
| Message-ID | <tfUQN-8fZ-5@gated-at.bofh.it> |
SPARC M7 processor adds additional metadata for memory address space that can be used to secure access to regions of memory. This additional metadata is implemented as a 4-bit tag attached to each cacheline size block of memory. A task can set a tag on any number of such blocks. Access to such block is granted only if the virtual address used to access that block of memory has the tag encoded in the uppermost 4 bits of VA. Any mismatch between tag encoded in VA and tag set on the memory block results in a trap. Tags are verified in the VA presented to the MMU and tags are associated with the physical page VA maps on to. If a memory page is swapped out and page frame gets reused for another task, the tags are lost and hence must be saved when swapping or migrating the page. A userspace task enables ADI through mprotect(). This patch series adds a page protection bit PROT_ADI and a corresponding VMA flag VM_SPARC_ADI. VM_SPARC_ADI is used to trigger setting TTE.mcd bit in the sparc pte that enables ADI checking on the corresponding page. MMU validates the tag embedded in VA for every page that has TTE.mcd bit set in its pte. After enabling ADI on a memory range, the userspace task can set ADI version tags using stxa instruction with ASI_MCD_PRIMARY or ASI_MCD_ST_BLKINIT_PRIMARY ASI. Once userspace task calls mprotect() with PROT_ADI, kernel takes following overall steps: 1. Find the VMAs covering the address range passed in to mprotect and set VM_SPARC_ADI flag. If address range covers a subset of a VMA, the VMA will be split. 2. When a page is allocated for a VA and the VMA covering this VA has VM_SPARC_ADI flag set, set the TTE.mcd bit so MMU will check the vwersion tag. 3. Userspace can now set version tags on the memory it has enabled ADI on. Userspace accesses ADI enabled memory using a virtual address that has the version tag embedded in the high bits. MMU validates this version tag against the actual tag set on the memory. If tag matches, MMU performs the VA->PA translation and access is granted. If there is a mismatch, hypervisor sends a data access exception or precise memory corruption detected exception depending upon whether precise exceptions are enabled or not (controlled by MCDPERR register). Kernel sends SIGSEGV to the task with appropriate si_code. 4. If a page is being swapped out or migrated, kernel builds a swap pte for the page. If the page is ADI enabled and has version tags set on it, set_swp_pte_at() function introduced by this patch series allows kernel to save the version tags. set_swp_pte_at() replaces the calls to set_pte_at() in functions that unmap and map a page. On architectures that do not require special handling on a page being swapped, set_swp_pte_at() defaults to set_pte_at(). In this initial implementation, kernel supports saving one version tag per page and top bits of swap offset in swap pte are used to store the tag. 5. When the page is swapped back in or reinstantiated after migration, set_swp_pte_at() function allows kernel to restore the version tags on the new physical page by retrieving the original tag from swap offset in swap pte. User task can disable ADI by calling mprotect() again on the memory range with PROT_ADI bit unset. Kernel clears the VM_SPARC_ADI flag in VMAs, merges adjacent VMAs if necessary, and clears TTE.mcd bit in the corresponding ptes. IOMMU does not support ADI checking. Any version tags embedded in the top bits of VA meant for IOMMU, are cleared and replaced with sign extension of the first non-version tag bit (bit 59 for SPARC M7) for IOMMU addresses. This patch series adds support for this feature in 4 patches: Patch 1/4 Tag mismatch on access by a task results in a trap from hypervisor as data access exception or a precide memory corruption detected exception. As part of handling these exceptions, kernel sends a SIGSEGV to user process with special si_code to indicate which fault occurred. This patch adds three new si_codes to differentiate between various mismatch errors. Patch 2/4 When a page is swapped or migrated, metadata associated with the page must be saved so it can be restored later. This patch adds a new function that saves/restores this metadata when updating pte upon a swap/migration. Patch 3/4 SPARC M7 processor adds new fields to control registers to support ADI feature. It also adds a new exception for precise traps on tag mismatch. This patch adds definitions for the new control register fields, new ASIs for ADI and an exception handler for the precise trap on tag mismatch. Patch 4/4 This patch adds support for a user space task to enable ADI and enable tag checking for subsets of its address space. As part of enabling this feature, this patch also extends exception handlers to handler tag mismatch exceptions, adds code to save and restore tags on page swap and migration, and adds code to return ADI parameters to userspace. Changelog v6: - Patch 1/4: No changes - Patch 2/4: No changes - Patch 3/4: Added missing nop in the delay slot in sun4v_mcd_detect_precise - Patch 4/4: Eliminated instructions to read and write PSTATE as well as MCDPER and PMCDPER on every access to userspace addresses by setting PSTATE and PMCDPER correctly upon entry into kernel Changelog v5: - Patch 1/4: No changes - Patch 2/4: Replaced set_swp_pte_at() with new architecture functions arch_do_swap_page() and arch_unmap_one() that suppoprt architecture specific actions to be taken on page swap and migration - Patch 3/4: Fixed indentation issues in assembly code - Patch 4/4: - Fixed indentation issues and instrcuctions in assembly code - Removed CONFIG_SPARC64 from mdesc.c - Changed to maintain state of MCDPER register in thread info flags as opposed to in mm context. MCDPER is a per-thread state and belongs in thread info flag as opposed to mm context which is shared across threads. Added comments to clarify this is a lazily maintained state and must be updated on context switch and copy_process() - Updated code to use the new arch_do_swap_page() and arch_unmap_one() functions Testing: - All functionality was tested with 8K normal pages as well as hugepages using malloc, mmap and shm. - Multiple long duration stress tests were run using hugepages over 2+ months. Normal pages were tested with shorter duration stress tests. - Tested swapping with malloc and shm by reducing max memory and allocating three times the available system memory by active processes using ADI on allocated memory. Ran through multiple hour long runs of this test. - Tested page migration with malloc and shm by migrating data pages of active ADI test process using migratepages, back and forth between two nodes every few seconds over an hour long run. Verified page migration through /proc/<pid>/numa_maps. Outstanding issues: - When sharing mmap'd ADI enabled areas with MAP_PRIVATE, copy-on-write results in a copy that does not have ADI enabled and ADI tags set. - Two processes sharing a mmap's ADI enabled area with MAP_SHARED must coordinate setting of ADI tags or else one process can cause the other to get SIGSEGV. I am working to solve these issues in subsequent patches. First issue can be resolved by mapping the new COW pages with ADI enabled and copy the ADI tags over to the new pages. This will increase the COW time since tags must be copied over one cacheline at a time. Second issue can possibly be solved by allowing only one task to mmap with write permission when the memory pages are ADI enabled. All subsequent mmap of this shared file would then be read-only mappings, or mprotect() with PROT_ADI would be denied for subsequent mappings if mapped pages have write permission. This would allow only one process to change ADI tags but that process can still cause the processes that have mmap'd read-only to crash if it changes ADI tags without coordinating the change with other processes. These ideas need to be explored more before implementing a fix. There are potential race conditions as well in the solution for second issue that will need to be evaluated and addressed. --- Khalid Aziz (4): signals, sparc: Add signal codes for ADI violations mm: Add functions to support extra actions on swap in/out sparc64: Add support for ADI register fields, ASIs and traps sparc64: Add support for ADI (Application Data Integrity) Documentation/sparc/adi.txt | 288 ++++++++++++++++++++++++++++++++ arch/sparc/include/asm/adi.h | 6 + arch/sparc/include/asm/adi_64.h | 46 +++++ arch/sparc/include/asm/elf_64.h | 8 + arch/sparc/include/asm/hugetlb.h | 13 ++ arch/sparc/include/asm/hypervisor.h | 2 + arch/sparc/include/asm/mman.h | 40 ++++- arch/sparc/include/asm/mmu_64.h | 1 + arch/sparc/include/asm/mmu_context_64.h | 42 +++++ arch/sparc/include/asm/pgtable_64.h | 87 +++++++++- arch/sparc/include/asm/thread_info_64.h | 2 +- arch/sparc/include/asm/trap_block.h | 2 + arch/sparc/include/asm/ttable.h | 10 ++ arch/sparc/include/uapi/asm/asi.h | 5 + arch/sparc/include/uapi/asm/auxvec.h | 8 + arch/sparc/include/uapi/asm/mman.h | 2 + arch/sparc/include/uapi/asm/pstate.h | 10 ++ arch/sparc/kernel/Makefile | 1 + arch/sparc/kernel/adi_64.c | 93 +++++++++++ arch/sparc/kernel/entry.h | 3 + arch/sparc/kernel/etrap_64.S | 28 +++- arch/sparc/kernel/head_64.S | 1 + arch/sparc/kernel/mdesc.c | 2 + arch/sparc/kernel/process_64.c | 25 +++ arch/sparc/kernel/setup_64.c | 11 +- arch/sparc/kernel/sun4v_mcd.S | 17 ++ arch/sparc/kernel/traps_64.c | 137 ++++++++++++++- arch/sparc/kernel/ttable_64.S | 6 +- arch/sparc/kernel/vmlinux.lds.S | 5 + arch/sparc/mm/gup.c | 37 ++++ arch/x86/kernel/signal_compat.c | 2 +- include/asm-generic/pgtable.h | 16 ++ include/linux/mm.h | 2 + include/uapi/asm-generic/siginfo.h | 5 +- mm/memory.c | 1 + mm/rmap.c | 2 + 36 files changed, 953 insertions(+), 13 deletions(-) create mode 100644 Documentation/sparc/adi.txt create mode 100644 arch/sparc/include/asm/adi.h create mode 100644 arch/sparc/include/asm/adi_64.h create mode 100644 arch/sparc/kernel/adi_64.c create mode 100644 arch/sparc/kernel/sun4v_mcd.S -- 2.7.4
[toc] | [next] | [standalone]
| From | Anthony Yznaga <anthony.yznaga@oracle.com> |
|---|---|
| Date | 2017-03-07 01:30 +0100 |
| Subject | Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) |
| Message-ID | <tibaN-7DV-3@gated-at.bofh.it> |
| In reply to | #1589695 |
> On Feb 28, 2017, at 10:35 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote: > > diff --git a/arch/sparc/kernel/etrap_64.S b/arch/sparc/kernel/etrap_64.S > index 1276ca2..7be33bf 100644 > --- a/arch/sparc/kernel/etrap_64.S > +++ b/arch/sparc/kernel/etrap_64.S > @@ -132,7 +132,33 @@ etrap_save: save %g2, -STACK_BIAS, %sp > stx %g6, [%sp + PTREGS_OFF + PT_V9_G6] > stx %g7, [%sp + PTREGS_OFF + PT_V9_G7] > or %l7, %l0, %l7 > - sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 > +661: sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 > + /* > + * If userspace is using ADI, it could potentially pass > + * a pointer with version tag embedded in it. To maintain > + * the ADI security, we must enable PSTATE.mcde. Userspace > + * would have already set TTE.mcd in an earlier call to > + * kernel and set the version tag for the address being > + * dereferenced. Setting PSTATE.mcde would ensure any > + * access to userspace data through a system call honors > + * ADI and does not allow a rogue app to bypass ADI by > + * using system calls. Setting PSTATE.mcde only affects > + * accesses to virtual addresses that have TTE.mcd set. > + * Set PMCDPER to ensure any exceptions caused by ADI > + * version tag mismatch are exposed before system call > + * returns to userspace. Setting PMCDPER affects only > + * writes to virtual addresses that have TTE.mcd set and > + * have a version tag set as well. > + */ > + .section .sun_m7_1insn_patch, "ax" > + .word 661b > + sethi %hi(TSTATE_TSO | TSTATE_PEF | TSTATE_MCDE), %l0 > + .previous > +661: nop > + .section .sun_m7_1insn_patch, "ax" > + .word 661b > + .word 0xaf902001 /* wrpr %g0, 1, %pmcdper */ Since PMCDPER is never cleared, setting it here is quickly going to set it on all CPUs and then become an expensive "nop" that burns ~50 cycles each time through etrap. Consider setting it at boot time and when a CPU is DR'd into the system. Anthony
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2017-03-07 01:40 +0100 |
| Subject | Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) |
| Message-ID | <tibkt-7Hd-3@gated-at.bofh.it> |
| In reply to | #1593812 |
On 03/06/2017 05:13 PM, Anthony Yznaga wrote: > >> On Feb 28, 2017, at 10:35 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote: >> >> diff --git a/arch/sparc/kernel/etrap_64.S b/arch/sparc/kernel/etrap_64.S >> index 1276ca2..7be33bf 100644 >> --- a/arch/sparc/kernel/etrap_64.S >> +++ b/arch/sparc/kernel/etrap_64.S >> @@ -132,7 +132,33 @@ etrap_save: save %g2, -STACK_BIAS, %sp >> stx %g6, [%sp + PTREGS_OFF + PT_V9_G6] >> stx %g7, [%sp + PTREGS_OFF + PT_V9_G7] >> or %l7, %l0, %l7 >> - sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >> +661: sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >> + /* >> + * If userspace is using ADI, it could potentially pass >> + * a pointer with version tag embedded in it. To maintain >> + * the ADI security, we must enable PSTATE.mcde. Userspace >> + * would have already set TTE.mcd in an earlier call to >> + * kernel and set the version tag for the address being >> + * dereferenced. Setting PSTATE.mcde would ensure any >> + * access to userspace data through a system call honors >> + * ADI and does not allow a rogue app to bypass ADI by >> + * using system calls. Setting PSTATE.mcde only affects >> + * accesses to virtual addresses that have TTE.mcd set. >> + * Set PMCDPER to ensure any exceptions caused by ADI >> + * version tag mismatch are exposed before system call >> + * returns to userspace. Setting PMCDPER affects only >> + * writes to virtual addresses that have TTE.mcd set and >> + * have a version tag set as well. >> + */ >> + .section .sun_m7_1insn_patch, "ax" >> + .word 661b >> + sethi %hi(TSTATE_TSO | TSTATE_PEF | TSTATE_MCDE), %l0 >> + .previous >> +661: nop >> + .section .sun_m7_1insn_patch, "ax" >> + .word 661b >> + .word 0xaf902001 /* wrpr %g0, 1, %pmcdper */ > > Since PMCDPER is never cleared, setting it here is quickly going to set it on all CPUs and then become an expensive "nop" that burns ~50 cycles each time through etrap. Consider setting it at boot time and when a CPU is DR'd into the system. > > Anthony > I considered that possibility. What made me uncomfortable with that is there is no way to prevent a driver/module or future code elsewhere in kernel from clearing PMCDPER with possibly good reason. If that were to happen, setting PMCDPER here ensures kernel will always see consistent behavior with system calls. It does come at a cost. Is that cost unacceptable to ensure consistent behavior? -- Khalid
[toc] | [prev] | [next] | [standalone]
| From | Anthony Yznaga <anthony.yznaga@oracle.com> |
|---|---|
| Date | 2017-03-07 02:30 +0100 |
| Subject | Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) |
| Message-ID | <tic6R-8lE-7@gated-at.bofh.it> |
| In reply to | #1593815 |
> On Mar 6, 2017, at 4:31 PM, Khalid Aziz <khalid.aziz@oracle.com> wrote: > > On 03/06/2017 05:13 PM, Anthony Yznaga wrote: >> >>> On Feb 28, 2017, at 10:35 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote: >>> >>> diff --git a/arch/sparc/kernel/etrap_64.S b/arch/sparc/kernel/etrap_64.S >>> index 1276ca2..7be33bf 100644 >>> --- a/arch/sparc/kernel/etrap_64.S >>> +++ b/arch/sparc/kernel/etrap_64.S >>> @@ -132,7 +132,33 @@ etrap_save: save %g2, -STACK_BIAS, %sp >>> stx %g6, [%sp + PTREGS_OFF + PT_V9_G6] >>> stx %g7, [%sp + PTREGS_OFF + PT_V9_G7] >>> or %l7, %l0, %l7 >>> - sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >>> +661: sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >>> + /* >>> + * If userspace is using ADI, it could potentially pass >>> + * a pointer with version tag embedded in it. To maintain >>> + * the ADI security, we must enable PSTATE.mcde. Userspace >>> + * would have already set TTE.mcd in an earlier call to >>> + * kernel and set the version tag for the address being >>> + * dereferenced. Setting PSTATE.mcde would ensure any >>> + * access to userspace data through a system call honors >>> + * ADI and does not allow a rogue app to bypass ADI by >>> + * using system calls. Setting PSTATE.mcde only affects >>> + * accesses to virtual addresses that have TTE.mcd set. >>> + * Set PMCDPER to ensure any exceptions caused by ADI >>> + * version tag mismatch are exposed before system call >>> + * returns to userspace. Setting PMCDPER affects only >>> + * writes to virtual addresses that have TTE.mcd set and >>> + * have a version tag set as well. >>> + */ >>> + .section .sun_m7_1insn_patch, "ax" >>> + .word 661b >>> + sethi %hi(TSTATE_TSO | TSTATE_PEF | TSTATE_MCDE), %l0 >>> + .previous >>> +661: nop >>> + .section .sun_m7_1insn_patch, "ax" >>> + .word 661b >>> + .word 0xaf902001 /* wrpr %g0, 1, %pmcdper */ >> >> Since PMCDPER is never cleared, setting it here is quickly going to set it on all CPUs and then become an expensive "nop" that burns ~50 cycles each time through etrap. Consider setting it at boot time and when a CPU is DR'd into the system. >> >> Anthony >> > > I considered that possibility. What made me uncomfortable with that is there is no way to prevent a driver/module or future code elsewhere in kernel from clearing PMCDPER with possibly good reason. If that were to happen, setting PMCDPER here ensures kernel will always see consistent behavior with system calls. It does come at a cost. Is that cost unacceptable to ensure consistent behavior? Aren't you still at risk if the thread relinquishes the CPU while in the kernel and is then rescheduled on a CPU where PMCDPER has erroneously been left cleared? You may need to save and restore PMCDPER as well as MCDPER on context switch, but I don't know if that will cover you completely. Alternatively you can avoid problems from buggy code and avoid the performance hit when storing to ADI enabled memory with precise mode enabled (e.g. when reading from a file into an ADI-enabled buffer) by handling disrupting mismatches that happen in copy_to_user() or put_user(). That does require adding error barriers and appropriate exception table entries, though, to deal with the nature of disrupting exceptions. Anthony > > -- > Khalid
[toc] | [prev] | [next] | [standalone]
| From | Khalid Aziz <khalid.aziz@oracle.com> |
|---|---|
| Date | 2017-03-07 17:50 +0100 |
| Subject | Re: [PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity) |
| Message-ID | <tiqtc-1LM-3@gated-at.bofh.it> |
| In reply to | #1593845 |
On 03/06/2017 06:25 PM, Anthony Yznaga wrote: > >> On Mar 6, 2017, at 4:31 PM, Khalid Aziz <khalid.aziz@oracle.com> wrote: >> >> On 03/06/2017 05:13 PM, Anthony Yznaga wrote: >>> >>>> On Feb 28, 2017, at 10:35 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote: >>>> >>>> diff --git a/arch/sparc/kernel/etrap_64.S b/arch/sparc/kernel/etrap_64.S >>>> index 1276ca2..7be33bf 100644 >>>> --- a/arch/sparc/kernel/etrap_64.S >>>> +++ b/arch/sparc/kernel/etrap_64.S >>>> @@ -132,7 +132,33 @@ etrap_save: save %g2, -STACK_BIAS, %sp >>>> stx %g6, [%sp + PTREGS_OFF + PT_V9_G6] >>>> stx %g7, [%sp + PTREGS_OFF + PT_V9_G7] >>>> or %l7, %l0, %l7 >>>> - sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >>>> +661: sethi %hi(TSTATE_TSO | TSTATE_PEF), %l0 >>>> + /* >>>> + * If userspace is using ADI, it could potentially pass >>>> + * a pointer with version tag embedded in it. To maintain >>>> + * the ADI security, we must enable PSTATE.mcde. Userspace >>>> + * would have already set TTE.mcd in an earlier call to >>>> + * kernel and set the version tag for the address being >>>> + * dereferenced. Setting PSTATE.mcde would ensure any >>>> + * access to userspace data through a system call honors >>>> + * ADI and does not allow a rogue app to bypass ADI by >>>> + * using system calls. Setting PSTATE.mcde only affects >>>> + * accesses to virtual addresses that have TTE.mcd set. >>>> + * Set PMCDPER to ensure any exceptions caused by ADI >>>> + * version tag mismatch are exposed before system call >>>> + * returns to userspace. Setting PMCDPER affects only >>>> + * writes to virtual addresses that have TTE.mcd set and >>>> + * have a version tag set as well. >>>> + */ >>>> + .section .sun_m7_1insn_patch, "ax" >>>> + .word 661b >>>> + sethi %hi(TSTATE_TSO | TSTATE_PEF | TSTATE_MCDE), %l0 >>>> + .previous >>>> +661: nop >>>> + .section .sun_m7_1insn_patch, "ax" >>>> + .word 661b >>>> + .word 0xaf902001 /* wrpr %g0, 1, %pmcdper */ >>> >>> Since PMCDPER is never cleared, setting it here is quickly going to set it on all CPUs and then become an expensive "nop" that burns ~50 cycles each time through etrap. Consider setting it at boot time and when a CPU is DR'd into the system. >>> >>> Anthony >>> >> >> I considered that possibility. What made me uncomfortable with that is there is no way to prevent a driver/module or future code elsewhere in kernel from clearing PMCDPER with possibly good reason. If that were to happen, setting PMCDPER here ensures kernel will always see consistent behavior with system calls. It does come at a cost. Is that cost unacceptable to ensure consistent behavior? > > Aren't you still at risk if the thread relinquishes the CPU while in the kernel and is then rescheduled on a CPU where PMCDPER has erroneously been left cleared? You may need to save and restore PMCDPER as well as MCDPER on context switch, but I don't know if that will cover you completely. > You mean something like this? --- arch/sparc/include/asm/mmu_context_64.h 2017-03-03 14:05:30.398573081 -0700 +++ /tmp/mmu_context_64.h 2017-03-07 08:26:20.582124798 -0700 @@ -193,6 +193,7 @@ __asm__ __volatile__( "mov %0, %%g1\n\t" ".word 0x9d800001\n\t" /* wr %g0, %g1, %mcdper" */ + ".word 0xaf902001\n\t" /* wrpr %g0, 1, %pmcdper */ : : "ir" (tmp_mcdper) : "g1"); > Alternatively you can avoid problems from buggy code and avoid the performance hit when storing to ADI enabled memory with precise mode enabled (e.g. when reading from a file into an ADI-enabled buffer) by handling disrupting mismatches that happen in copy_to_user() or put_user(). That does require adding error barriers and appropriate exception table entries, though, to deal with the nature of disrupting exceptions. > put_user() can be called for writing just one word of data to the userspace and memory barrier for that is as expensive as running with the worst case with PMCDPER set. PMCDPER being set only affects writes to ADI-enabled userpsace VAs while barrier affects every write. A memory barrier before we return from kernel can ensure any exceptions due to userspace memory access are exposed while we are still in the kernel but the cost is high and it affects writes to non-ADI enabled memory as well. Doing this for copy_to_user() makes more sense due to larger number of writes. I still think it is more effective to run in the kernel with PMCDPER set, and clear it in NG4copy_to_user() for the larger number of copies. Clearing can be done conditionally if any of the memory kernel is about to write to is ADI enabled. This can be done as a separate optimization patch if it makes sense. This does add more code to NG4copy_to_user(). Thoughts? Thanks, Khalid
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web