st bit of dynticks?
> >
> > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> > CPUs are the moment?
> >
> > All of this was introduced in:
> > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
>
On 8/14/19 2:17 PM, Lendacky, Thomas wrote:
From: Tom Lendacky
There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from BIOS
not performing the proper steps during resume to ensure RDRAND continues
to function prop
On Aug 13, 2019, at 4:02 PM, Dave Hansen wrote:
>>
>> static inline pte_t pte_mkwrite(pte_t pte)
>> {
>> +pte = pte_move_flags(pte, _PAGE_DIRTY_SW, _PAGE_DIRTY_HW);
>>return pte_set_flags(pte, _PAGE_RW);
>> }
>
> It also isn't clear to me why this *must* move bits here. Its doubly
>
On Tue, Aug 13, 2019 at 2:02 PM Yu-cheng Yu wrote:
>
> When a task does fork(), its shadow stack (SHSTK) must be duplicated
> for the child. This patch implements a flow similar to copy-on-write
> of an anonymous page, but for SHSTK.
>
> A SHSTK PTE must be RO and dirty. This dirty bit requireme
On Thu, Jun 27, 2019 at 2:39 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > Also, I don't think there's any actual requirement that the upstream
> > kernel recognize existing CET-enabled RHEL 8 binaries as being
> > CET-enabled. I tend to think that RH
On Fri, Jun 28, 2019 at 12:50 PM Yu-cheng Yu wrote:
>
> The IBT bitmap is visiable from user-mode, but not writable.
>
> Signed-off-by: Yu-cheng Yu
>
> ---
> arch/x86/mm/fault.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 59f4
> On Jun 28, 2019, at 12:41 PM, Yu-cheng Yu wrote:
>
> The CET legacy code bitmap covers the whole user-mode address space and is
> located at the top of the user-mode address space. It is allocated only
> when the first time arch_prctl(ARCH_X86_MARK_LEGACY_CODE) is called from
> an application.
> On Jun 28, 2019, at 12:41 PM, Yu-cheng Yu wrote:
>
> The previous discussion of the IBT legacy code bitmap is here:
>
>https://lkml.org/lkml/2019/6/6/1032
>
> When CET Indirect Branch Tracking (IBT) is enabled, the processor expects
> every branch target is an ENDBR instruction, or the
On Thu, May 2, 2019 at 4:10 AM Dave Martin wrote:
>
> On Wed, May 01, 2019 at 02:12:17PM -0700, Yu-cheng Yu wrote:
> > An ELF file's .note.gnu.property indicates features the executable file
> > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > indicates the file supports
> On Jun 14, 2019, at 3:06 PM, Dave Hansen wrote:
>
>> On 6/14/19 2:34 PM, Yu-cheng Yu wrote:
>> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
I have a related question:
Do we allow the application to read the bitmap, or any fault from the
application on bitmap pag
> On Jun 10, 2019, at 5:08 PM, Dave Hansen wrote:
>
>> On 6/10/19 4:54 PM, Andy Lutomirski wrote:
>> Another benefit of kernel management: we could plausibly auto-clear
>> the bits corresponding to munmapped regions. Is this worth it?
>
> I did it for MPX. I th
> On Jun 10, 2019, at 3:59 PM, Dave Hansen wrote:
>
>> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
>> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
>> VM_DONTDUMP. The bitmap will cover only 48-bit address space.
>
> Could you make sure to discuss the downsides of only doin
On Mon, Jun 10, 2019 at 12:52 PM Dave Hansen wrote:
>
> On 6/10/19 12:38 PM, Yu-cheng Yu wrote:
> >>> When an application starts, its highest stack address is determined.
> >>> It uses that as the maximum the bitmap needs to cover.
> >> Huh, I didn't think we ran code from the stack. ;)
> >>
> >>
> On Jun 7, 2019, at 2:09 PM, Dave Hansen wrote:
>
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>>> Huh, how does glibc know about all possible past and future legacy code
>>> in the application?
>> When dlopen() gets a legacy binary and the policy allows that, it will manage
>> the bitmap:
>>
>>
> On Jun 7, 2019, at 12:49 PM, Yu-cheng Yu wrote:
>
> On Fri, 2019-06-07 at 11:29 -0700, Andy Lutomirski wrote:
>>> On Jun 7, 2019, at 10:59 AM, Dave Hansen wrote:
>>>
>>>> On 6/7/19 10:43 AM, Peter Zijlstra wrote:
>>>> I've no idea w
> On Jun 7, 2019, at 11:58 AM, Dave Hansen wrote:
>
> On 6/7/19 11:29 AM, Andy Lutomirski wrote:
> ...
>>> I think this new MSR probably needs to get included in oops output when
>>> CET is enabled.
>>
>> This shouldn’t be able to OOPS because it o
> On Jun 7, 2019, at 10:59 AM, Dave Hansen wrote:
>
>> On 6/7/19 10:43 AM, Peter Zijlstra wrote:
>> I've no idea what the kernel should do; since you failed to answer the
>> question what happens when you point this to garbage.
>>
>> Does it then fault or what?
>
> Yeah, I think you'll fault
> On Jun 7, 2019, at 9:45 AM, Yu-cheng Yu wrote:
>
> On Fri, 2019-06-07 at 09:35 -0700, Andy Lutomirski wrote:
>>> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu wrote:
>>>
>>>>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>>>&
> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu wrote:
>
>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
>>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
>>> that allows execution of legacy, non-IB
> On Jun 6, 2019, at 3:08 PM, Dave Hansen wrote:
>
>
>
> On 6/6/19 3:04 PM, Andy Lutomirski wrote:
>>> But, that seems broken. If we have supervisor state, we can't
>>> always defer the load until return to userspace, so we'll never??
>>&
On Jun 6, 2019, at 2:18 PM, Dave Hansen wrote:
>> +/*
>> + * Helpers for changing XSAVES system states.
>> + */
>> +static inline void modify_fpu_regs_begin(void)
>> +{
>> +fpregs_lock();
>> +if (test_thread_flag(TIF_NEED_FPU_LOAD))
>> +__fpregs_load_activate();
>> +}
>> +
>> +
On Thu, Jun 6, 2019 at 1:17 PM Yu-cheng Yu wrote:
>
> From: "H.J. Lu"
>
> Add ENDBR64 to vsyscall entry points.
I'm still okay with this patch, but this is rather silly. If anyone
actually executes this code, they're doing it wrong.
--Andy
On Thu, Jun 6, 2019 at 1:17 PM Yu-cheng Yu wrote:
>
> When emulating a RET, also unwind the task's shadow stack and cancel
> the current branch tracking status.
>
> Signed-off-by: Yu-cheng Yu
> ---
> arch/x86/entry/vsyscall/vsyscall_64.c | 28 +++
> 1 file changed, 28 ins
n=branch so that it
> can be used to compile vDSO.
Acked-by: Andy Lutomirski
>
> Signed-off-by: H.J. Lu
You're still missing your Signed-off-by.
On Thu, Jun 6, 2019 at 1:17 PM Yu-cheng Yu wrote:
>
> From: "H.J. Lu"
>
> Add ENDBR32 to __kernel_vsyscall entry point.
>
Acked-by: Andy Lutomirski
However, you forgot your own Signed-off-by.
> Signed-off-by: H.J. Lu
--Andy
On Mon, Nov 26, 2018 at 9:44 AM Yu-cheng Yu wrote:
>
> On Thu, 2018-11-22 at 08:53 -0800, Andy Lutomirski wrote:
> > [cc some more libc folks]
>
> >
> > 2. I want to be able to modify the signal context from a signal
> > handler such that, when the signal handler
On Thu, Nov 22, 2018 at 12:04 PM Matthew Wilcox wrote:
>
> On Thu, Nov 22, 2018 at 09:27:02PM +0200, Igor Stoppa wrote:
> > I have studied the code involved with Nadav's patchset.
> > I am perplexed about these sentences you wrote.
> >
> > More to the point (to the best of my understanding):
> >
>
[cc some more libc folks]
I have a general question about this patch set:
If I'm writing a user program, and I write a signal handler, there are
two things I want to make sure I can still do:
1. I want to be able to unwind directly from the signal handler
without involving sigreturn() -- that is
> On Nov 21, 2018, at 4:21 PM, Daniel Colascione wrote:
>
>> On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton
>> wrote:
>>
>>> On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascione
>>> wrote:
>>>
On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton
wrote:
> On Wed, 21 Nov 2018
> On Nov 21, 2018, at 9:34 AM, Igor Stoppa wrote:
>
> Hi,
>
>>> On 13/11/2018 20:36, Andy Lutomirski wrote:
>>> On Tue, Nov 13, 2018 at 10:33 AM Igor Stoppa wrote:
>>>
>>> I forgot one sentence :-(
>>>
>>>>>
On Mon, Nov 19, 2018 at 1:55 PM Yu-cheng Yu wrote:
>
> From: "H.J. Lu"
>
> Add ENDBR32 to vsyscall entry point.
$SUBJECT should be "x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point".
--Andy
On Mon, Nov 19, 2018 at 1:55 PM Yu-cheng Yu wrote:
>
> From: "H.J. Lu"
>
> Add ENDBR64 to vsyscall entry points.
>
> Signed-off-by: H.J. Lu
Acked-by: Andy Lutomirski
although the scenarios where this matters will be extremely rare,
given that this code is mapped
On Mon, Nov 19, 2018 at 1:55 PM Yu-cheng Yu wrote:
>
> From: "H.J. Lu"
>
> When Intel indirect branch tracking is enabled, functions in vDSO which
> may be called indirectly must have endbr32 or endbr64 as the first
> instruction. Compiler must support -fcf-protection=branch so that it
> can be
On Tue, Nov 13, 2018 at 10:31 AM Igor Stoppa wrote:
>
> On 13/11/2018 19:47, Andy Lutomirski wrote:
>
> > For general rare-writish stuff, I don't think we want IRQs running
> > with them mapped anywhere for write. For AVC and IMA, I'm less sure.
>
> Why wo
On Tue, Nov 13, 2018 at 10:33 AM Igor Stoppa wrote:
>
> I forgot one sentence :-(
>
> On 13/11/2018 20:31, Igor Stoppa wrote:
> > On 13/11/2018 19:47, Andy Lutomirski wrote:
> >
> >> For general rare-writish stuff, I don't think we want IRQs running
> >
On Tue, Nov 13, 2018 at 10:26 AM Igor Stoppa wrote:
>
> On 13/11/2018 19:16, Andy Lutomirski wrote:
>
> > should be
> > entirely abstracted away by an appropriate API, so neither SELinux nor
> > IMA need to be aware that there's an mm_struct involved.
>
> Y
On Tue, Nov 13, 2018 at 9:43 AM Nadav Amit wrote:
>
> From: Andy Lutomirski
> Sent: November 13, 2018 at 5:16:09 PM GMT
> > To: Igor Stoppa
> > Cc: Kees Cook , Peter Zijlstra
> > , Nadav Amit , Mimi Zohar
> > , Matthew Wilcox , Dave
> > Chinner , Ja
, so I am resuming this discussion.
>
> On 30/10/2018 19:06, Andy Lutomirski wrote:
>
> > I support the addition of a rare-write mechanism to the upstream kernel.
> > And I think that there is only one sane way to implement it: using an
> > mm_struct. That mm_struct, just lik
> On Nov 11, 2018, at 3:31 AM, Pavel Machek wrote:
>
> Hi!
>
>>> +/*
>>> + * State component 12 is Control flow Enforcement kernel states
>>> + */
>>> +struct cet_kernel_state {
>>> +u64 kernel_ssp;/* kernel shadow stack */
>>> +u64 pl1_ssp;/* ring-1 shadow stack */
>>> +u
> On Nov 9, 2018, at 12:06 PM, Jann Horn wrote:
>
> +Andy, Thomas, Ingo
>
>> On Fri, Nov 9, 2018 at 2:24 PM kernel test robot wrote:
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
On Thu, Nov 8, 2018 at 4:32 PM Matthew Wilcox wrote:
>
> On Thu, Nov 08, 2018 at 03:35:02PM -0800, Dave Hansen wrote:
> > On 11/8/18 2:00 PM, Matthew Wilcox wrote:
> > > struct a {
> > > char c;
> > > struct b b;
> > > };
> > >
> > > we want struct b to start at offset 8, but with __packed
On Thu, Nov 8, 2018 at 1:31 PM Cyrill Gorcunov wrote:
>
> On Thu, Nov 08, 2018 at 01:22:54PM -0800, Andy Lutomirski wrote:
> > > >
> > > > Why are these __packed? It seems like it'll generate bad code for no
> > > > obvious purpose.
> > &g
On Thu, Nov 8, 2018 at 1:06 PM Yu-cheng Yu wrote:
>
> On Thu, 2018-11-08 at 12:46 -0800, Andy Lutomirski wrote:
> > On Thu, Oct 11, 2018 at 8:20 AM Yu-cheng Yu wrote:
> > >
> > > Intel Control-flow Enforcement Technology (CET) introduces the
> > > follo
On Thu, Oct 11, 2018 at 8:20 AM Yu-cheng Yu wrote:
>
> Intel Control-flow Enforcement Technology (CET) introduces the
> following MSRs into the XSAVES system states.
>
> IA32_U_CET (user-mode CET settings),
> IA32_PL3_SSP (user-mode shadow stack),
> IA32_PL0_SSP (kernel-mode shadow sta
On Tue, Nov 6, 2018 at 10:43 AM Dave Hansen wrote:
>
> On 10/11/18 8:15 AM, Yu-cheng Yu wrote:
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -1305,6 +1305,15 @@ __do_page_fault(struct pt_regs *regs, unsigned long
> > error_code,
> > error_code |= X86_PF_USER;
>
On Wed, Oct 31, 2018 at 4:10 PM Igor Stoppa wrote:
>
>
>
> On 01/11/2018 00:57, Andy Lutomirski wrote:
> >
> >
> >> On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
>
>
>
> >> I _think_ the use-case for atomics is updating the reference counts
> On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
>
>> On Wed, Oct 31, 2018 at 01:36:48PM -0700, Andy Lutomirski wrote:
>>
>>>> On Oct 31, 2018, at 3:02 AM, Peter Zijlstra wrote:
>>>>
>>>> On Tue, Oct 30, 2018 at 09:41:13PM -070
> On Oct 31, 2018, at 1:38 PM, Andy Lutomirski wrote:
>
>
>
>>> On Oct 31, 2018, at 3:11 AM, Peter Zijlstra wrote:
>>>
>>> On Wed, Oct 31, 2018 at 12:15:46AM +0200, Igor Stoppa wrote:
>>> On 30/10/2018 23:02, Andy Lutomirski wrote:
>&
> On Oct 31, 2018, at 3:11 AM, Peter Zijlstra wrote:
>
>> On Wed, Oct 31, 2018 at 12:15:46AM +0200, Igor Stoppa wrote:
>> On 30/10/2018 23:02, Andy Lutomirski wrote:
>
>>> But I dislike allowing regular writes in the protected region. We
>>> really only
> On Oct 31, 2018, at 3:02 AM, Peter Zijlstra wrote:
>
>> On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
>> To clarify some of this thread, I think that the fact that rare_write
>> uses an mm_struct and alias mappings under the hood should be
>>
On Tue, Oct 30, 2018 at 2:36 PM Matthew Wilcox wrote:
>
> On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
> > On 30/10/2018 21:20, Matthew Wilcox wrote:
> > > > > So the API might look something like this:
> > > > >
> > > > > void *p = rare_alloc(...); /* writable pointer
> On Oct 30, 2018, at 1:43 PM, Igor Stoppa wrote:
>
>> On 30/10/2018 21:20, Matthew Wilcox wrote:
>>> On Tue, Oct 30, 2018 at 12:28:41PM -0600, Tycho Andersen wrote:
>>>> On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
>>>> O
> On Oct 30, 2018, at 10:58 AM, Matthew Wilcox wrote:
>
> On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
>>> On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
>> I support the addition of a rare-write mechanism to the upstream kernel.
>> And I thi
> On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
>
>> On Tue, Oct 30, 2018 at 8:26 AM, Peter Zijlstra wrote:
>> I suppose the 'normal' attack goes like:
>>
>> 1) find buffer-overrun / bound check failure
>> 2) use that to write to 'interesting' location
>> 3) that write results arbitrary code
On Wed, May 16, 2018 at 1:19 AM Yury Norov wrote:
>
> This series enables AARCH64 with ILP32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used b
> On Oct 13, 2018, at 2:34 AM, Catalin Marinas wrote:
>
>> On Sat, Oct 13, 2018 at 04:14:16AM +0200, Eugene Syromiatnikov wrote:
>>> On Wed, Oct 10, 2018 at 04:36:56PM +0100, Catalin Marinas wrote:
On Wed, Oct 10, 2018 at 04:10:21PM +0200, Eugene Syromiatnikov wrote:
I have some question
On Thu, Oct 11, 2018 at 1:39 PM Jann Horn wrote:
>
> On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu wrote:
> > Create a guard area between VMAs to detect memory corruption.
> [...]
> > +config VM_AREA_GUARD
> > + bool "VM area guard"
> > + default n
> > + help
> > + Create
On Sat, Oct 6, 2018 at 10:03 AM Ingo Molnar wrote:
>
>
> There's one PTI related layout asymmetry I noticed between 4-level and
> 5-level kernels:
>
> 47-bit:
> > +|
> > +| Ke
On Fri, Oct 5, 2018 at 10:03 AM Yu-cheng Yu wrote:
>
> On Fri, 2018-10-05 at 09:28 -0700, Andy Lutomirski wrote:
> > > On Oct 5, 2018, at 9:13 AM, Yu-cheng Yu wrote:
> > >
> > > > On Wed, 2018-10-03 at 21:57 +0200, Eugene Syromiatnikov wrote:
> > >
> On Oct 5, 2018, at 9:13 AM, Yu-cheng Yu wrote:
>
>> On Wed, 2018-10-03 at 21:57 +0200, Eugene Syromiatnikov wrote:
>>> On Fri, Sep 21, 2018 at 08:05:47AM -0700, Yu-cheng Yu wrote:
>>> Indirect branch tracking provides an optional legacy code bitmap
>>> that indicates locations of non-IBT com
On Thu, Oct 4, 2018 at 9:08 AM Florian Weimer wrote:
>
> * Yu-cheng Yu:
>
> > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
> >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
> >> > Branch Tracki
On Fri, Sep 21, 2018 at 8:10 AM Yu-cheng Yu wrote:
>
> Indirect branch tracking provides an optional legacy code bitmap
> that indicates locations of non-IBT compatible code. When set,
> each bit in the bitmap represents a page in the linear address is
> legacy code.
>
> We allocate the bitmap on
> On Oct 4, 2018, at 8:37 AM, Yu-cheng Yu wrote:
>
>> On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
>>> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
>>> Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
>>> Branch Tracking features.
>>>
>>> Introduce:
On Wed, Oct 3, 2018 at 9:06 AM Yu-cheng Yu wrote:
>
> On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
> > >
> > > On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > >
On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
>
> On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > Create a guard area between VMAs, to detect memory corruption.
>
> Do I understand correctly that with this patch a user space program
> no longer be able to place two ma
On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption mask that indicates
> the PGD is encrypted. The encryption mask should not be used when
> creating a virtual address from the cr3 register, so remove the SME
> encryption mask in the read
On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote:
> On 6/8/2017 1:05 AM, Andy Lutomirski wrote:
>>
>> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky
>> wrote:
>>>
>>> The cr3 register entry can contain the SME encryption bit that indicates
>>>
On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption bit that indicates
> the PGD is encrypted. The encryption bit should not be used when creating
> a virtual address for the PGD table.
>
> Create a new function, read_cr3_pa(), that will ex
On Tue, May 23, 2017 at 11:36 AM, Kees Cook wrote:
> On Tue, May 23, 2017 at 12:48 AM, Solar Designer wrote:
>> For modules_autoload_mode=2, we already seem to have the equivalent of
>> modprobe=/bin/true (or does it differ subtly, maybe in return values?),
>> which I already use at startup on a
On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote:
> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote:
>> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote:
>>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote:
>
On 09/28/2016 07:44 AM, Amir Levy wrote:
This patch provides the communication protocol between the
Intel Connection Manager(ICM) firmware that is operational in the
Thunderbolt controller in non-Apple hardware.
The ICM firmware-based controller is used for establishing and maintaining
the Thunde
On Tue, Nov 8, 2016 at 8:25 PM, Ricardo Neri
wrote:
> On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote:
>> > diff --git a/arch/x86/include/asm/disabled-features.h
>> b/arch/x86/include/asm/disabled-features.h
>> > index 85599ad..4707445 100644
>> >
On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
wrote:
> On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
>> > Would it not be better to emulate these instructions for them? What
>> way
>> > we can verify they're not malicious.
>>
>> Forget malice
n virtual-8086 mode.
>
> Since the X86_UMIP config option is not defined yet, this code remains
> dormant until such option is enabled in a subsequent patch. Such patch will
> also introduce code to disable UMIP for virtual-8086 tasks via a kernel
> parameter.
>
> Cc: Andy Lutom
Forget malice -- if they are really needed for some silly vm86-using
program, let's trap them and emulate them so they return dummy values.
Also, keep in mind that vm86 is already effectively gated behind a
sysctl for non-root. I think the default should be that, if root has
enabled vm
obal Descriptor Table
> * SIDT - Store Interrupt Descriptor Table
> * SLDT - Store Local Descriptor Table
> * SMSW - Store Machine Status Word
> * STR - Store Task Register
>
> If any of these instructions is executed with CPL > 0, a general protection
> exception is iss
On Fri, Nov 4, 2016 at 6:14 AM, Christopher Covington
wrote:
> Applications such as Just-In-Time (JIT) compilers, Checkpoint/Restore In
> Userspace (CRIU), and User Mode Linux (UML) need to know the highest
> virtual address, TASK_SIZE, to implement pointer tagging or make a first
> educated guess
On Sep 9, 2016 1:40 PM, "Chris Metcalf" wrote:
>
> On 9/2/2016 1:28 PM, Andy Lutomirski wrote:
>>
>> On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
>>>
>>> On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
>>>>
>>>> O
On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote:
>
> BOOT data (such as EFI related data) is not encyrpted when the system is
> booted and needs to be accessed as non-encrypted. Add support to the
> early_memremap API to identify the type of data being accessed so that
> the proper encryption attri
On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
>
> On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf
>> wrote:
>>>
>>> On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
>>>>
>&
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
> On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
>>
>> On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>>>
>>> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
>>>>
>>>> On Tue,
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>
> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
>>>
>>> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
>>>>
>>
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
>>
>> On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
>>>
>>> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
>>>
On Aug 30, 2016 6:34 AM, "Tom Lendacky" wrote:
>
> On 08/25/2016 08:04 AM, Thomas Gleixner wrote:
> > On Mon, 22 Aug 2016, Tom Lendacky wrote:
> >
> >> Provide support for Secure Memory Encryption (SME). This initial support
> >> defines the memory encryption mask as a variable for quick access an
On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf wrote:
> On 7/14/2016 5:03 PM, Andy Lutomirski wrote:
>>
>> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf
>> wrote:
>>>
>>> Here is a respin of the task-isolation patch set. This primarily
>>> refl
On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf wrote:
> Here is a respin of the task-isolation patch set. This primarily
> reflects feedback from Frederic and Peter Z.
I still think this is the wrong approach, at least at this point. The
first step should be to instrument things if necessary an
On Fri, Jun 24, 2016 at 12:04 PM, Kees Cook wrote:
> On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper wrote:
>> Thomas,
>>
>> Sorry for wandering off the topic of your series. The big take away for
>> me is that you and Kees are concerned about x86 systems pre-RDRAND.
>> Just as I'm concerned about
On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote:
> On 06/23/16 23:46, Andrew Morton wrote:
>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote:
>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer
On May 13, 2016 2:42 AM, "Dr. Greg Wettstein" wrote:
>
> On Sun, May 08, 2016 at 06:32:10PM -0700, Andy Lutomirski wrote:
>
> Good morning, running behind on e-mail this week but wanted to get
> some reflections out on Andy's well taken comments and concerns.
>
On Fri, May 6, 2016 at 4:35 AM, Jarkko Sakkinen
wrote:
> On Thu, May 05, 2016 at 05:52:31PM -0700, Andy Lutomirski wrote:
>> On Thu, May 5, 2016 at 3:45 PM, Jarkko Sakkinen
>> wrote:
>> > On Mon, Apr 25, 2016 at 01:01:06PM -0700, Andy Lutomirski wrote:
>> >
On Fri, May 6, 2016 at 4:23 AM, Jarkko Sakkinen
wrote:
> On Wed, Apr 27, 2016 at 10:18:05AM +0200, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>> > > What new syscalls would be needed for ssh to get all this support?
>> >
>> > This patc
On Thu, May 5, 2016 at 3:45 PM, Jarkko Sakkinen
wrote:
> On Mon, Apr 25, 2016 at 01:01:06PM -0700, Andy Lutomirski wrote:
>> On 04/25/2016 10:34 AM, Jarkko Sakkinen wrote:
>> >+SGX_IOCTL_ENCLAVE_INIT
>> >+
>> >+Initializes an enclave given by SIGSTRUCT and
On Wed, Apr 27, 2016 at 1:10 PM, Tom Lendacky wrote:
> On 04/27/2016 09:39 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky
>> wrote:
>>> This RFC patch series provides support for AMD's new Secure Memory
>>> Encryption (SME) fe
On Wed, Apr 27, 2016 at 8:31 AM, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 08:12:56AM -0700, Andy Lutomirski wrote:
>> I think there are some errata
>
> Isn't that addressed by the first branch of the if-test in pat_init():
>
> if ((c->x
On Wed, Apr 27, 2016 at 8:05 AM, Tom Lendacky wrote:
> On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky
>> wrote:
>>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>>>> On Tue, Apr 26, 2016 at 3:56 PM, Tom
On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote:
> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky
>> wrote:
>>> For AMD processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP)
On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote:
> For AMD processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
What's the purpose of using the WP memory type?
--Andy
--
To unsubscribe from this list: send the li
On Apr 27, 2016 1:18 AM, "Ingo Molnar" wrote:
>
>
> * Andy Lutomirski wrote:
>
> > > What new syscalls would be needed for ssh to get all this support?
> >
> > This patchset or similar, plus some user code and an enclave to use.
> >
> > S
On Tue, Apr 26, 2016 at 2:52 PM, Pavel Machek wrote:
> On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
>> > But... that will mean that my ssh will need to be SGX-aware, and that
>> > I will not be able to switch to AMD machine in future. ... or to other
>> > Intel machine for that matter, r
1 - 100 of 121 matches
Mail list logo
