> Still setup_cpu_number() sucks.
How about setup_cpu_and_node_number()?
Thanks,
Chang
> Ah. You copied it from here where it makes no sense either. Copy and paste
> is useful, but you really want to think about it.
That's the matter of fact though, let me revise those you pointed out here.
> This patch wants to be split into:
> 1) Adding the new functions
> 2) Convert vd
On Friday, 22 Jun 2018, Thomas Gleixner wrote:
> On Wed, 20 Jun 2018, Chang S. Bae wrote:
> > CPU number initialization in vDSO is now a bit cleaned up by
> > the new helper functions. The helper functions will take
> > care of combing CPU and node number and reading each from
> s/combing/combini
On 3/19/2018 01:05 PM, Dave Hansen wrote:
>> When FSGSBASE is enabled, SWAPGS needs if and only if (current)
>> GS base is not the kernel's.
> Do you mean "SWAPGS is needed..."?
Yes, will change.
>> FSGSBASE instructions allow user to write any value on GS base;
>> even negative. Sign check on the
On 3/20/18, 07:58, "Andy Lutomirski" wrote:
>> On Mar 19, 2018, at 10:49 AM, Chang S. Bae wrote:
>>
>> When FSGSBASE is enabled, SWAPGS needs if and only if (current)
>> GS base is not the kernel's.
>>
>> FSGSBASE instructions allow user to write any value on GS base;
>> even negative. Sign che
On 3/20/18, 08:07, "Andy Lutomirski" wrote:
> Can you describe what changed since the last submission? It looks
> like a lot has changed and this series is much more complicated and
> much more fragile than it used to be. Why?
According to your overall comments, most concerning part you have ri
On 3/20/18, 08:05, "Andy Lutomirski" wrote:
> I've also suggested something like this myself, but this approach is
> far more complicated than the older approach. Was there something
> that the old approach would break? If so, what?
Sorry, I don't know your suggestion. Can you elaborate your sug
On 3/20/18, 07:58, "Andy Lutomirski" wrote:
> The original version of these patches (mine and Andi’s) didn’t have
> this comparison, didn’t need RDMSR, and didn’t allow malicious user
To be clear, RDMSR is not needed (with FSGSBASE)
> I would prefer calling it something like FIND_PERCPU_BASE or something like
> that.
Thanks for the suggestion.
Chang
On 3/20/18, 17:47, "Andy Lutomirski" wrote:
>If I've understood all your emails right, when you looked at existing
>ptrace users, you found that all of them that write to gs and/or
>gs_base do it as part of a putregs call that writes them at the same
>time. If so, then your patch
> Summary please.
These deltas I found as comparing with your old codes [4]
* Paranoid entry changes to avoid vulnerability
* Ptrace changes to support the legacy behavior (conditionally)
* Dropped [1] to be aligned with what is concluded in [3]
* Dropped [2] since save_fsgs() doesn’t copy base w
On 3/21/18, 18:41, "Andy Lutomirski" wrote:
> mov to gs changes GSBASE even if GS was unchanged.
In GDB, ptrace (syscall) doesn't happen when FS/GS unchanged as
its (context) cache seems to be first checked. This does not allow to
preserve GSBASE as you know.
> But it's not clear to me that yo
> But your patch doesn't actually do this, since gdb will just do
> SETREGS anyway, right?
GDB does SETREGS on any exclusive (FS/GS) updates in inferior call.
From: Andy Lutomirski [l...@kernel.org]
Sent: Thursday, March 22, 2018 09:53
>>> But your patch doesn't actually do this, since gdb will just do
>>> SETREGS anyway, right?
>> GDB does SETREGS on any exclusive (FS/GS) updates in inferior call.
> This means
On Nov 6, 2018, at 17:23, Andy Lutomirski wrote:
>
> On Thu, Nov 1, 2018 at 1:32 PM Chang S. Bae wrote:
>>
>> @@ -392,12 +384,7 @@ int x86_fsbase_write_task(struct task_struct *task,
>> unsigned long fsbase)
>>if (unlikely(fsbase >= TASK_SIZE_MAX))
>>return -EPERM;
>>
> On Nov 14, 2018, at 13:46, Bae, Chang Seok wrote:
>
> int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
> @@ -758,11 +720,45 @@ long do_arch_prctl_64(struct task_struct *task, int
> option, unsigned long arg2)
>
> switch (option) {
>
> Couldn't setup_cpu_number_segment()'s contents go in setup_cpu_number()?
Okay. I will do that.
Okay, will fix. Thanks
-Original Message-
From: Andy Lutomirski [mailto:l...@kernel.org]
Sent: Thursday, May 31, 2018 1:16 PM
On Thu, May 31, 2018 at 10:58 AM Chang S. Bae wrote:
>
> When new FSGSBASE instructions enabled, this read will be switched to
> be faster.
s/switched to be/be
>> Notion of "active" and "inactive" are used to distinguish
>> GS bases between "kernel" and "user". "inactive" GS base
>> is the GS base, backed up at kernel entries, of inactive
>> (user) task's.
> I'm fine with the code, but the changelog entry is confusing. A bunch
> of the active helpers do
>> +/* Bit size and mask of CPU number stored in the per CPU data */
>> +#define PERCPU_CPU_SIZE12
>> +#define PERCPU_CPU_MASK0xfff
> This name is confusing. Maybe LSL_TSCP_CPU_MASK?
> Can you also add a helpers like:
> static inline unsigned long
> 1. Can you try and generate a new version of patches 1-5 quickly? I think it
> would be nice to get them merged this cycle.
Okay, let me reply, first, what I can do now. Will do submit patches with
revisions, (as soon as I can).
> Factor out the code to change index from x86_fsbase_write_cpu() and
> x86_gsbase_write_cpu_inactive(). Now the code is located in
> do_arch_prctl_64().
>
> The helper functions that purport to write the base register should just
> write the
> base register only. It shouldn't have magic optimiza
> On Oct 30, 2018, at 14:25, Andy Lutomirski wrote:
>
> On Tue, Oct 30, 2018 at 10:28 AM Chang S. Bae
> wrote:
>>
>> Factor out the code to change index from x86_fsbase_write_cpu() and
>> x86_gsbase_write_cpu_inactive(). Now the code is located in
>> do_arch_prctl_64().
>>
>
>> @@ -359,9
On Tue, Sep 18, 2018 at 12:02 PM Andy Lutomirski
> On Tue, Sep 18, 2018 at 4:09 PM Chang S. Bae
> wrote:
> >
> > With new helpers, FS/GS base access is centralized.
> > Eventually, when FSGSBASE instruction enabled, it will be faster.
>
> Sorry for not catching this during review, but:
>
> > +v
On Wed, Oct 24, 2018 at 12:22 PM Andy Lutomirski
> On Wed, Oct 24, 2018 at 12:13 PM Bae, Chang Seok
> wrote:
> >
> > On Tue, Sep 18, 2018 at 12:02 PM Andy Lutomirski
> > > On Tue, Sep 18, 2018 at 4:09 PM Chang S. Bae
> > >
> > > wrote:
> >
On Tue, Oct 24, 2018 at 12:21 PM Andy Lutomirski wrote:
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> wrote:
> >
> > From: Andy Lutomirski
> >
> > With the new FSGSBASE instructions, we can efficiently read and write
> > the FSBASE and GSBASE in __switch_to(). Use that capability to preserv
On Wed, Oct 24, 2018 at 12:43 PM Andy Lutomirski wrote:
> I think x86_fsbase_write_task() makes plenty of sense, but I think
> that callers need to be aware that the effect of writing a nonzero
> fsbase *and* a nonzero fsindex is bizarre on non-FSGSBASE systems. So
> that code should go in the ca
>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>> index ea554f8..e716e94 100644
>> --- a/arch/x86/kernel/setup_percpu.c
>> +++ b/arch/x86/kernel/setup_percpu.c
>> @@ -155,12 +155,21 @@ static void __init pcpup_populate_pte(unsigned long
>> addr)
>>
>> static inl
On Wed, Jun 6, 2018 at 10:25 AM Andy Lutomirski wrote:
> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae wrote:
>>
>> The CPU (and node) number will be written, as early enough,
>> to the segment limit of per CPU data and TSC_AUX MSR entry.
>> The information has been retrieved by vgetcpu in user spa
> On Wed, Jun 6, 2018 at 10:25 AM Andy Lutomirski wrote:
>> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae wrote:
>> +static inline void setup_cpu_number_segment(int cpu)
>> +{
>> +#ifdef CONFIG_NUMA
>> + unsigned long node = early_cpu_to_node(cpu);
>> +#else
>> + unsigned long node = 0;
On Jan 27, 2021, at 01:38, Borislav Petkov wrote:
> On Wed, Jan 27, 2021 at 01:23:35AM +0000, Bae, Chang Seok wrote:
>> Okay. I will prepare a separate cleanup patch that can be applied at the end
>> of the series. Will post the change in this thread at first.
>
> No, this
On Jan 26, 2021, at 12:17, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:03AM -0800, Chang S. Bae wrote:
>>
>> +int alloc_xstate_buffer(struct fpu *fpu, u64 mask)
>> +if (newsz > fpu_kernel_xstate_max_size) {
>> +pr_warn_once("x86/fpu: xstate buffer too large (%u > %u
On Jan 27, 2021, at 02:41, Borislav Petkov wrote:
> On Wed, Jan 27, 2021 at 01:23:57AM +0000, Bae, Chang Seok wrote:
>> The xstate buffer may expand on the fly. The size has to be correctly
>> calculated if needed. CPUID provides essential information for the
>> calculatio
On Jan 28, 2021, at 02:34, Rafael J. Wysocki wrote:
> On Wed, Dec 16, 2020 at 6:47 PM Chang S. Bae wrote:
>>
>> + keybackup_status = read_keylocker_backup_status();
>> + if (!(keybackup_status & BIT(0))) {
>> + pr_err("x86/keylocker: internal key restoration failed with
On Feb 8, 2021, at 04:33, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:04AM -0800, Chang S. Bae wrote:
>> init_fpstate is used to record the initial xstate value for convenience
>
> convenience?
Yes, this is vague. I think the usage is when (re-)initializing the register
states, e.g. f
On Nov 24, 2020, at 10:41, Jann Horn wrote:
> On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
> wrote:
>>> On Nov 20, 2020, at 15:04, Jann Horn wrote:
>>> On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae
>>> wrote:
>>>>
>>>> diff --
This is related to the SS_AUTODISARM flag [1]:
I will include the fix in v6.
Thanks,
Chang
https://lore.kernel.org/lkml/81df502f-9327-4365-ad17-21cfae94e...@intel.com/
On Feb 9, 2021, at 04:49, Borislav Petkov wrote:
> On Mon, Feb 08, 2021 at 06:53:23PM +0000, Bae, Chang Seok wrote:
> Yours does. So drop it from this one and from all the other patches as
> it is causing more confusion than it is trying to dispel.
Okay.
>> I think they are
On Feb 8, 2021, at 04:33, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:06AM -0800, Chang S. Bae wrote:
>> copy_xregs_to_kernel() used to save all user states in a kernel buffer.
>> When the dynamic user state is enabled, it becomes conditional which state
>> to be saved.
>>
>> fpu->stat
On Feb 8, 2021, at 04:33, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:05AM -0800, Chang S. Bae wrote:
>> The struct fpu includes two (possible) xstate buffers -- fpu->state and
>> fpu->state_ptr. Instead of open code for accessing one of them, provide a
>> wrapper that covers both cases
> On Aug 20, 2020, at 02:15, Borislav Petkov wrote:
>
> From: Borislav Petkov
>
> The FSGSBASE macro to swap current GSBASE with the kernel GSBASE
> probably had a speculation-stopping MSR write at some point but not
> anymore.
No, the macro has not any MSR write ever before.
> diff --git a/
> On Aug 20, 2020, at 08:21, Tom Lendacky wrote:
> On 8/20/20 10:10 AM, Sean Christopherson wrote:
>>
>> Pretty sure current->thread.gsbase can be stale, i.e. this needs:
>> current_save_fsgs();
>
> I did try adding current_save_fsgs() in svm_vcpu_load(), saving the
> current->thread.gsb
> On Jan 11, 2021, at 13:06, Andy Lutomirski wrote:
>
>> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
>>
>> Or do you mean I should add "unsafe_fsgsbase" to grub cmdline and bisect
>> with fsgsbase enabled in all test kernels?
>
> Yes. But I can also look myself in a bit.
I was able
> On Dec 20, 2020, at 03:59, Andy Lutomirski wrote:
>
> On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae wrote:
>>
>> Key Locker [1][2] is a new security feature available in new Intel CPUs to
>> protect data encryption keys for the Advanced Encryption Standard
>> algorithm. The protection limits
> On Dec 8, 2020, at 02:12, Borislav Petkov wrote:
>
> On Thu, Nov 19, 2020 at 03:32:36PM -0800, Chang S. Bae wrote:
> > The xstate infrastructure is not flexible to support dynamic areas in
> > task->fpu.
>
> task->fpu?
It was considered to be concise to represent, but it looks to be
unreadab
> On Dec 3, 2020, at 14:00, Andy Lutomirski wrote:
>
> Have you confirmed that real ptrace users (gdb? does anything
> actually use this code?) can handle the huge buffers that will be
> needed?
Yes, we thought there is actual usage for this. We (cc'ing Markus) will
support it on GDB.
Thanks,
On Jan 19, 2021, at 07:57, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 07:47:38PM +0000, Bae, Chang Seok wrote:
>> On Jan 15, 2021, at 05:39, Borislav Petkov wrote:
>>> On Wed, Dec 23, 2020 at 07:57:01AM -0800, Chang S. Bae wrote:
>>>> The perf has a buffer th
On Jan 15, 2021, at 04:50, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:56:58AM -0800, Chang S. Bae wrote:
>>
>> -void copy_xstate_to_kernel(struct membuf to, struct xregs_state *xsave);
>> -int copy_kernel_to_xstate(struct xregs_state *xsave, const void *kbuf);
>> -int copy_user_to_xstate
On Jan 15, 2021, at 05:18, Borislav Petkov wrote:
>
> What I would've written is:
>
> "Have all functions handling FPU state take a struct fpu * pointer in
> preparation for dynamic state buffer support."
>
> Plain and simple.
Thank you. I will apply this on my next revision.
Chang
> On Jan 7, 2021, at 17:41, Liu, Jing2 wrote:
>
> static void kvm_save_current_fpu(struct fpu *fpu) {
> + struct fpu *src_fpu = ¤t->thread.fpu;
> +
> /*
>* If the target FPU state is not resident in the CPU registers, just
>* memcpy() from current, else save CPU state
> On Dec 23, 2020, at 10:37, Randy Dunlap wrote:
>
> On 12/23/20 7:57 AM, Chang S. Bae wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 44fde25bb221..a67ae04d43c5 100644
>> --- a/Documentation/admin-guide/kerne
> On Dec 23, 2020, at 07:56, Bae, Chang Seok wrote:
>
> Changes from v2 [5]:
> * Removed the patch for the tile data inheritance. Also, updated the
> selftest patch. (Andy Lutomirski)
> * Changed the kernel tainted when any unknown state is enabled. (Andy
> Lutomirski)
&
> On Jan 11, 2021, at 18:52, Liu, Jing2 wrote:
>
> On 1/8/2021 2:40 AM, Bae, Chang Seok wrote:
>>> On Jan 7, 2021, at 17:41, Liu, Jing2 wrote:
>>>
>>> static void kvm_save_current_fpu(struct fpu *fpu) {
>>> + struct fpu *src_fpu = ¤t->threa
On Mar 24, 2021, at 22:12, Liu, Jing2 wrote:
> On 3/25/2021 5:09 AM, Len Brown wrote:
>>
>> For AMX, we must still reserve the space, but we are not going to write zeros
>> for clean state. We so this in software by checking XINUSE=0, and clearing
>> the xstate_bf for the XSAVE. As a result, fo
On Mar 25, 2021, at 09:20, Borislav Petkov wrote:
>
> $ gcc tst-minsigstksz-2.c -DMY_MINSIGSTKSZ=3453 -o tst-minsigstksz-2
> $ ./tst-minsigstksz-2
> tst-minsigstksz-2: changed byte 50 bytes below configured stack
>
> Whoops.
>
> And the debug print said:
>
> [ 5395.252884] signal: get_sigframe
On Mar 25, 2021, at 11:54, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 11:13:12AM -0700, Andy Lutomirski wrote:
>> diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
>> index ea794a083c44..53781324a2d3 100644
>> --- a/arch/x86/kernel/signal.c
>> +++ b/arch/x86/kernel/signal.c
>>
On Mar 20, 2021, at 14:26, Thomas Gleixner wrote:
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>> In 64-bit mode, include the AMX state components in
>> XFEATURE_MASK_USER_SUPPORTED.
>>
>> The XFD feature will be used to dynamically expand the xstate per-task
>> buffer on the first use.
>
On Mar 20, 2021, at 14:31, Thomas Gleixner wrote:
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>>
>> +static void check_xtile_data_against_struct(int size)
>> +{
>> +u32 max_palid, palid, state_size;
>> +u32 eax, ebx, ecx, edx;
>> +u16 max_tile;
>> +
>> +/*
>> + * Check
On Mar 20, 2021, at 14:25, Thomas Gleixner wrote:
>
> And you could have changed the existing table just so:
>
> static unsigned short xsave_cpuid_features[] __initdata = {
> [XFEATURE_FP] = X86_FEATURE_FPU,
> [XFEATURE_SSE] = X86_FEAT
On Mar 20, 2021, at 15:13, Thomas Gleixner wrote:
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>> +
>> +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
>> +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
>> +{
>> +if (!static_cpu_has(X86_FEATURE
On Mar 16, 2021, at 04:52, Borislav Petkov wrote:
> On Mon, Mar 15, 2021 at 11:52:14PM -0700, Chang S. Bae wrote:
>> @@ -272,7 +275,8 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs
>> *regs, size_t frame_size,
>> * If we are on the alternate signal stack and would overflow it, don't
On Mar 26, 2021, at 09:34, Jann Horn wrote:
> On Sun, Feb 21, 2021 at 7:56 PM Chang S. Bae wrote:
>>
>> + if (handle_xfirstuse_event(¤t->thread.fpu))
>> + return;
>
> What happens if handle_xfirstuse_event() fails because vmalloc()
> failed in alloc_xstate_buffer()? I think
On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
>> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
>> style, when we fail to send a signal.
>
> Yeap, we should be able to tell userspace that we couldn't sen
On Feb 19, 2021, at 07:00, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:07AM -0800, Chang S. Bae wrote:
>>
>>
>> +/*
>> + * Available once those arrays for the offset, size, and alignment info are
>> set up,
>> + * by setup_xstate_features().
>> + */
>
> That's kinda clear, right? Ap
On Feb 21, 2021, at 11:30, Randy Dunlap wrote:
> Can we tell people (in this Doc file) where to look up the values that can be
> used in xstate.enable and xstate.disable?
Perhaps add something like this with the change below:
“See comment before function fpu__init_parse_early_param() in
> On Nov 25, 2020, at 20:17, Borislav Petkov wrote:
>
> On Thu, Nov 19, 2020 at 11:02:34AM -0800, Chang S. Bae wrote:
>> diff --git a/arch/x86/include/asm/sigframe.h
>> b/arch/x86/include/asm/sigframe.h
>> index 84eab2724875..ac77f3f90bc9 100644
>> --- a/arch/x86/include/asm/sigframe.h
>> +++ b
> On Nov 20, 2020, at 15:04, Jann Horn wrote:
>
> On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae wrote:
>>
>> diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
>> index ee6f1ceaa7a2..cee41d684dc2 100644
>> --- a/arch/x86/kernel/signal.c
>> +++ b/arch/x86/kernel/signal.c
>> @@ -25
> On Nov 19, 2020, at 21:07, Andy Lutomirski wrote:
>
> On Thu, Nov 19, 2020 at 3:37 PM Chang S. Bae wrote:
>>
>>
>> diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c
>> index 8d863240b9c6..6b9d0c0a266d 100644
>> --- a/arch/x86/kernel/fpu/regset.c
>> +++ b/arch/x86/ker
> On Nov 24, 2020, at 10:41, Jann Horn wrote:
>
> On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
> wrote:
>>> On Nov 20, 2020, at 15:04, Jann Horn wrote:
>>> On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae
>>> wrote:
>>>>
>>>> d
> On Nov 24, 2020, at 12:47, Jann Horn wrote:
>
> On Tue, Nov 24, 2020 at 9:43 PM Bae, Chang Seok
> wrote:
>>> On Nov 24, 2020, at 10:41, Jann Horn wrote:
>>> On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
>>> wrote:
>>>>> On Nov 20,
> On Dec 18, 2020, at 04:10, Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 09:41:42AM -0800, Chang S. Bae wrote:
>> When the system state switches to these sleep states, the internal key gets
>> reset. Since this system transition is transparent to userspace, the
>> internal key needs to be r
> On Dec 18, 2020, at 04:10, Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote:
>> [1] Intel Architecture Instruction Set Extensions Programming Reference:
>>
>> https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instructi
> On Dec 18, 2020, at 19:11, Peter Zijlstra wrote:
>
> *groan*, so what actual version of binutils is needed and why is this
> driver important enough to build on ancient crud to warrant all this
> gunk?
The new Key Locker instructions look to be added a few month ago [1].
But the latest binuti
> On Dec 18, 2020, at 18:59, Peter Zijlstra wrote:
>
> On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
>> +/* ENCODEKEY128 %EAX */
>> +asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
>
> This is lacking a binutils version number.
I will add the version number when an
> On Nov 25, 2020, at 03:33, Andy Lutomirski wrote:
>
> On Tue, Nov 24, 2020 at 10:22 AM Bae, Chang Seok
> wrote:
>>
>>
>>> On Nov 19, 2020, at 21:07, Andy Lutomirski wrote:
>>>
>>> On Thu, Nov 19, 2020 at 3:37 PM Chang S. Bae
>>&
On Jan 20, 2021, at 12:53, Borislav Petkov wrote:
> On Tue, Jan 19, 2021 at 06:50:52PM +0000, Bae, Chang Seok wrote:
>> I will add a sentence like this if looks fine:
>>
>> "The copy functions used to have ‘xstate' in the name as they took a struct
>>
On Mar 1, 2021, at 11:09, Borislav Petkov wrote:
> On Sat, Feb 27, 2021 at 08:59:06AM -0800, Chang S. Bae wrote:
>>
>> diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
>> index abe5f2b6581b..15be98c75174 100644
>> --- a/include/uapi/linux/auxvec.h
>> +++ b/include/uapi/linux
On Mar 5, 2021, at 02:43, Borislav Petkov wrote:
> On Sat, Feb 27, 2021 at 08:59:08AM -0800, Chang S. Bae wrote:
>> Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for
>> use by all architectures with sigaltstack(2). Over time, the hardware state
>> size grew, but these consta
On Mar 10, 2021, at 09:43, Borislav Petkov wrote:
>
> No, build the docs by doing
>
> make htmldocs
>
> and look at the result.
>
> Btw, you should always look at the result before sending it out.
Ah, now I get that. Sorry for my ignorance. I will fix and make sure not
missing this check.
Th
On Jan 26, 2021, at 12:17, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:03AM -0800, Chang S. Bae wrote:
>>
>> +/*
>> + * @state_mask:
>> + *
>> + * The state component bitmap. It indicates the saved xstate in
>> + * either @state or @state_ptr. The map value starts t
On Jan 22, 2021, at 02:56, Borislav Petkov wrote:
> On Tue, Jan 19, 2021 at 06:57:26PM +0000, Bae, Chang Seok wrote:
>> This series attempts to save the AMX state in the context switch buffer only
>
> What is the context switch buffer?
>
> I think you mean simply the x
On Jan 22, 2021, at 03:44, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:02AM -0800, Chang S. Bae wrote:
>> The xstate buffer is currently in-line with static size. To accommodatea
>
> "in-line" doesn't fit in this context, especially since "inline"
> is a keyword with another meaning. P
On Jan 15, 2021, at 05:39, Borislav Petkov wrote:
> On Wed, Dec 23, 2020 at 07:57:01AM -0800, Chang S. Bae wrote:
>> The perf has a buffer that is allocated on demand. The states saved in the
>
> What's "the perf"? I hope to find out when I countinue reading…
Maybe it was better to write ‘Linux
> On Sep 27, 2019, at 14:25, Randy Dunlap wrote:
>
> Hi,
> Some doc comments/fixes below...
>
> On 9/12/19 1:06 PM, Chang S. Bae wrote:
>> From: Thomas Gleixner
>>
[snip]
>> +There exist two mechanisms to read and write the FS/FS base address:
>
>
> On Sep 12, 2019, at 21:10, Andy Lutomirski wrote:
>
> I also think that, before this series can have my ack, it needs an actual gdb
> maintainer to chime in, publicly, and state that they have thought about and
> tested the ABI changes and that gdb still works on patched kernels with and
>
> On Jan 16, 2019, at 21:09, Andi Kleen wrote:
>
>> +#ifdef CONFIG_X86_64
>> +
>> +#include
>> +
>> +.macro RDGSBASE opd
>
> The caller can now use the assembler instructions directly, so the macros
> are not needed anymore.
>
> -Andi
Yeah, you’re right, since GAS is included in the binutils
> On Mar 25, 2019, at 02:44, Thomas Gleixner wrote:
>
> On Fri, 15 Mar 2019, Chang S. Bae wrote:
>
>> The FSGSBASE instructions allow fast accesses on GSBASE. Now, at the
>> paranoid_entry, the per-CPU base value can be always copied to GSBASE.
>> And the original GSBASE value will be restor
> On Apr 5, 2019, at 06:50, Andy Lutomirski wrote:
>
>
>
>> On Apr 5, 2019, at 2:35 AM, Thomas Gleixner wrote:
>>
>>> On Mon, 25 Mar 2019, Thomas Gleixner wrote:
On Fri, 15 Mar 2019, Chang S. Bae wrote:
ENTRY(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY
> On Mar 25, 2019, at 02:02, Thomas Gleixner wrote:
>
> On Fri, 15 Mar 2019, Chang S. Bae wrote:
>
>> diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
>> index f5a796da07f8..d063841a17e3 100644
>> --- a/arch/x86/include/asm/inst.h
>> +++ b/arch/x86/include/asm/inst.h
>> @
> On May 1, 2019, at 10:40, Andy Lutomirski wrote:
>
> On Wed, May 1, 2019 at 6:52 AM Bae, Chang Seok
> wrote:
>>
>>
>>> On Apr 5, 2019, at 06:50, Andy Lutomirski wrote:
>>>
>>>
>>>
>>>> On Apr 5, 2019, at 2:35 AM,
> On May 1, 2019, at 13:25, Andy Lutomirski wrote:
>
>
>
>> On May 1, 2019, at 1:21 PM, Bae, Chang Seok wrote:
>>
>>
>>>> On May 1, 2019, at 11:01, Bae, Chang Seok wrote:
>>>>
>>>> On May 1, 2019, at 10:40, Andy Lutomirski
> On Jul 2, 2019, at 14:38, Andy Lutomirski wrote:
>
> @@ -494,16 +489,24 @@ static void test_ptrace_write_gsbase(void)
>* selector value is changed or not by the GSBASE write in
>* a ptracer.
>*/
> - if (gs != 0x7) {
> + i
> On May 8, 2019, at 03:02, Chang S. Bae wrote:
>
> ENTRY(paranoid_exit)
> …
> +
> + /* On FSGSBASE systems, always restore the stashed GSBASE */
> + wrgsbase%rbx
> + jmp .Lparanoid_exit_no_swapgs;
It would crash any time getting a paranoid entry with user GS but kernel
> On Feb 2, 2019, at 09:17, Andy Lutomirski wrote:
>
> On Fri, Feb 1, 2019 at 12:55 PM Chang S. Bae wrote:
>>
>> +
>> +/*
>> + * CPU/node NR is loaded from the limit (size) field of a special segment
>> + * descriptor entry in GDT.
>> + */
>> +.macro LOAD_CPU_AND_NODE_SEG_LIMIT reg:req
>> +
On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> >
> > +/*
> > + * The FP state frame contains an XSAVE buffer which must be 64-byte
> > aligned.
> > + * If a signal frame starts at an unaligned address, extra space is
> > re
On Wed, 2020-10-07 at 11:05 +0100, Dave Martin wrote:
> On Tue, Oct 06, 2020 at 05:45:24PM +0000, Bae, Chang Seok wrote:
> > On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> > > On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> > > >
> > &g
> On Aug 20, 2020, at 21:41, Kyle Huey wrote:
>
> On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
> running under rr[0]. Booting the kernel with `nofsgsbase` fixes it and
> I bisected to
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.8&i
> On Aug 21, 2020, at 14:32, Kyle Huey wrote:
>
> 40c45904f818c1f6555294ca27afc5fda4f09e68 added magic for a 32 bit
> tracer tracing a 32 bit tracee on a 64 bit kernel, but it looks like a
> 64 bit tracer tracing a 32 bit tracee on a 64 bit kernel *is* now
> expected to preserve the fs/gsbase v
On Wed, 2020-10-14 at 09:29 -0700, Dave Hansen wrote:
> On 10/14/20 9:10 AM, Andy Lutomirski wrote:
> >
> > I was suggesting something a little bit different. We'd keep XMM,
> > YMM, ZMM, etc state stored exactly the way we do now and, for
> > AMX-using tasks, we would save the AMX state in an en
On Tue, 2020-11-03 at 13:41 -0800, Dave Hansen wrote:
> On 11/3/20 1:32 PM, Bae, Chang Seok wrote:
> > On Wed, 2020-10-14 at 09:29 -0700, Dave Hansen wrote:
> > > On 10/14/20 9:10 AM, Andy Lutomirski wrote:
> > > > I was suggesting something a little bit different. W
1 - 100 of 105 matches
Mail list logo
