On Fri, Jan 5, 2018 at 5:40 AM, Borislav Petkov wrote:
> On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
>> It's RFC because I want to re-read it myself first. It's also missing
>> a test that will reliably make sure that vsyscall=none prevents use of
On Fri, Jan 5, 2018 at 9:52 AM, Greg Kroah-Hartman
wrote:
> On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote:
>> Boots successfully with "noefi" kernel parameter :)
>
> Thanks, that will help me narrow it down. I'll dig through more patches
> when I get home tonight...
I wish you l
On Fri, Jan 5, 2018 at 10:30 AM, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 10:01:23AM -0800, Andy Lutomirski wrote:
>> Yes. There are very clever tools like 'pin' that instrument a binary
>> by decoding all the instructions it executes and generating an
>&
On Fri, Jan 5, 2018 at 10:23 AM, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote:
>> emulate_noread would avoid one exploit technique that Kees saw
>> somewhere. And per-process disablement would let a system remain
>> compatible with
> On Jan 5, 2018, at 11:10 AM, Borislav Petkov wrote:
>
>> On Fri, Jan 05, 2018 at 10:45:49AM -0800, Andy Lutomirski wrote:
>> Not _PAGE_RW. Probably _PAGE_USER somewhere in the hierarchy.
>
> Yeah, just realized that. But it must be somewhere in th
> On Jan 5, 2018, at 11:28 AM, Borislav Petkov wrote:
>
>> On Fri, Jan 05, 2018 at 11:22:21AM -0800, Andy Lutomirski wrote:
>> It's emulated! We catch the page fault and fake the whole thing :)
>
> Then I'm really confused. It says "ro" above, which
> On Jan 5, 2018, at 1:00 PM, Harry Wentland wrote:
>
> Since rebasing our dev trees on v4.15-rc2 a bunch of our systems are failing
> to resume from S3. I've bisected it to the following commit
>
> commit ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 (refs/bisect/bad)
&g
> On Jan 5, 2018, at 1:14 PM, Jiri Kosina wrote:
>
> On Fri, 5 Jan 2018, Dave Hansen wrote:
>
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
>save_pgd[pgd] = *pgd_offset_k(pgd *
> On Jan 5, 2018, at 1:51 PM, Harry Wentland wrote:
>
>> On 2018-01-05 04:28 PM, Andy Lutomirski wrote:
>> It's a known issue, and it should be fixed in newer -rc kernels.
>>
>
> I'm still seeing this on v4.15-rc6. Will I need rc7 or the latest x86
On Fri, Jan 26, 2018 at 6:24 AM, Alan Cox wrote:
>> NetBSD (and the other BSD?) defines a structure for the arguments to
>> each syscall.
>
> Goes back to v7 or so but they put the syscall arguments into the uarea
> so that no pointers were needed (uarea being a per process mapping at a
> fixed ad
On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>
> We've noticed that fsgsbase_64 can fail intermittently with the
> following error:
>
> [RUN] ARCH_SET_GS(0x0) and clear gs, then schedule to 0x1
> Before schedule, set selector to 0x1
> other thread: ARCH
On Fri, Jan 26, 2018 at 10:13 AM, Linus Torvalds
wrote:
> On Fri, Jan 26, 2018 at 10:07 AM, Al Viro wrote:
>>
>> Umm... What about other architectures? Or do you want SYSCALL_DEFINE...
>> to be per-arch? I wonder how much would that "go through pt_regs" hurt
>> on something like sparc...
>
> N
On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>>
>> We've noticed that fsgsbase_64 can fail intermittently with the
>> following error:
>>
>> [RUN] ARCH_SET_GS(0x0) and clear gs, then sch
On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov
wrote:
> On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
>> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
>> uses large amounts of vmalloc space with PTI enabled.
>>
>> The ca
On Fri, Jan 26, 2018 at 10:54 AM, Linus Torvalds
wrote:
> On Fri, Jan 26, 2018 at 10:23 AM, Andy Lutomirski wrote:
>>
>> The issue is that doing it this way gives us, effectively:
>>
>> long sys_foo(int a, int b)
>> {
>> body here;
>> }
On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
>> On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>>>
>>> We've noticed that fsgsbase_64 can fail intermittently with the
>>> following e
On Fri, Jan 26, 2018 at 11:46 AM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote:
>> On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
>>> On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>>>>
>>>> We've n
On Fri, Jan 26, 2018 at 2:38 PM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 11:46 AM, Andy Lutomirski wrote:
>> On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote:
>>> On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
>>>> On Fri, Jan 26, 2
> On Jan 28, 2018, at 1:29 AM, Ingo Molnar wrote:
>
>
> * Dan Williams wrote:
>
>> Quoting Linus:
>>
>> "Honestly, I'd rather get rid of the fast-path entirely. Compared to
>> all the PTI mess, it's not even noticeable.
>>
>> And if we ever get CPU's that have this all fixed, we can
.
Just get rid of the fast path. The slow path is barely slower.
Signed-off-by: Andy Lutomirski
---
This isn't quite identical to Linus' patch. I cleaned up the
SYSCALL64 entry code to use all pushes rather than pushing all but 6
regs and moving the rest.
arch/x86/entry/entry_64
__SYSCALL_DEFINE is rather magical. Add a bit of documentation.
Signed-off-by: Andy Lutomirski
---
include/linux/syscalls.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a78186d826d7..d3f244a447c5 100644
--- a/include
Three changes in here:
- Get rid of the SYSCALL64 fast path as suggested by Linus.
- Move TS_COMPAT into the same cacheline as thread_info::flags, also
suggested by Linus.
- Document SYSCALL_DEFINE a bit better.
Andy Lutomirski (3):
x86/entry/64: Remove the SYSCALL64 fast path
x86/asm
heline even in pure
64-bit code that never needs to modify status hurts performance.
That could be a reasonable followup patch, but I suspect it matters
less on top of this patch.
Suggested-by: Linus Torvalds
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 4 ++--
arch/x
On Fri, Jan 26, 2018 at 2:42 PM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 2:38 PM, Andy Lutomirski wrote:
>> On Fri, Jan 26, 2018 at 11:46 AM, Andy Lutomirski wrote:
>>> On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote:
>>>> On Fri, Jan 26, 20
On Fri, Jan 26, 2018 at 2:56 PM, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 02:38:28PM -0800, Andy Lutomirski wrote:
>> Borislav, any chance you could run the attached program on an AMD
>> machine to see what it does?
>
> [boris@pd: /tmp> ./gs1
> PID = 3420
> a
> On Jan 28, 2018, at 12:21 PM, Konrad Rzeszutek Wilk
> wrote:
>
>> On January 28, 2018 2:29:10 PM EST, KarimAllah Ahmed
>> wrote:
>> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
>> guests
>> that will only mitigate Spectre V2 through IBRS+IBPB and will not be
>> usi
> On Jan 28, 2018, at 12:44 PM, David Woodhouse wrote:
>
>> On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
>>
>> Do you mean that the host would intercept the guest WRMSR and do
>> WRMSR itself? I would suggest that doing so is inconsistent with the
On Mon, Jan 29, 2018 at 1:13 AM, H. Peter Anvin wrote:
> On 01/28/18 11:21, Andy Lutomirski wrote:
>>>
>>> I think the bug is here. I think that, when writing a NULL selector
>>> to DS, ES, FS, or GS, Intel CPUs incorrectly set DPL == RPL, whereas
>>>
> On Jan 29, 2018, at 10:12 AM, H. Peter Anvin wrote:
>
>> On 01/29/18 08:37, Andy Lutomirski wrote:
>>
>> That's what I thought, too, and the SDM does say that, but the SDM
>> says all kinds of not-quite-correct things about segmentation.
>>
&g
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Hi,
>
> here is my current WIP code to enable PTI on x86-32. It is
> still in a pretty early state, but it successfully boots my
> KVM guest with PAE and with legacy paging. The existing PTI
> code for x86-64 already pr
On Tue, Jan 16, 2018 at 12:30 PM, Thomas Gleixner wrote:
> On Tue, 16 Jan 2018, Joerg Roedel wrote:
>> @@ -89,13 +89,9 @@ static inline void refresh_sysenter_cs(struct
>> thread_struct *thread)
>> /* This is used when switching tasks or entering/exiting vm86 mode. */
>> static inline void updat
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Use the sysenter stack as a trampoline stack to enter the
> kernel. The sysenter stack is already in the cpu_entry_area
> and will be mapped to userspace when PTI is enabled.
>
> Signed-off-by: Joerg Roedel
> ---
> ar
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Move it out of the X86_64 specific processor defines so
> that its visible for 32bit too.
Hmm. This is okay, I guess, but any code that actually uses this
definition is inherently wrong, since 32-bit implies !PCID.
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Switch back to the trampoline stack before returning to
> userspace.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/entry/entry_32.S| 58
>
> arch/x86/kernel/asm-off
On Tue, Jan 16, 2018 at 8:52 AM, Peter Zijlstra wrote:
> On Tue, Jan 16, 2018 at 05:36:49PM +0100, Joerg Roedel wrote:
>> From: Joerg Roedel
>>
>> Reserve 2MB/4MB of address space for mapping the LDT to
>> user-space.
>
> LDT is 64k, we need 2 per CPU, and NR_CPUS <= 64 on 32bit, that gives
> 64K
thieu Desnoyers
> Reviewed-by: Thomas Gleixner
> CC: Peter Zijlstra
> CC: Andy Lutomirski
> CC: Paul E. McKenney
> CC: Boqun Feng
> CC: Andrew Hunter
> CC: Maged Michael
> CC: Avi Kivity
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Michael Ellerman
On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel wrote:
> On Tue, Jan 16, 2018 at 02:45:27PM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
>> > +.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0
>>
>> How about marking nr_re
On Wed, Jan 17, 2018 at 6:10 AM, Joerg Roedel wrote:
> On Wed, Jan 17, 2018 at 05:57:53AM -0800, Brian Gerst wrote:
>> On Wed, Jan 17, 2018 at 1:24 AM, Joerg Roedel wrote:
>
>> > I have no real idea on how to switch back to the entry stack without
>> > access to per_cpu variables. I also can't ac
On Wed, Jan 17, 2018 at 10:10 AM, Mathieu Desnoyers
wrote:
> - On Jan 17, 2018, at 12:53 PM, Andy Lutomirski l...@kernel.org wrote:
>
>> On Wed, Jan 17, 2018 at 8:54 AM, Mathieu Desnoyers
>> wrote:
>>> Ensure that a core serializing instruction is issued before
On Wed, Jan 17, 2018 at 3:25 PM, Mathieu Desnoyers
wrote:
> - On Jan 17, 2018, at 1:13 PM, Andy Lutomirski l...@kernel.org wrote:
>
>> On Wed, Jan 17, 2018 at 10:10 AM, Mathieu Desnoyers
>> wrote:
>>> - On Jan 17, 2018, at 12:53 PM, Andy Lutomirski l...@kernel
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Also populate the user-spage pgd's in the user page-table.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/pgtable-2level.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/include/asm
On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Allocate a kernel and a user page-table root when PTI is
> enabled. Also allocate a full page per root for PAEm because
> otherwise the bit to flip in cr3 to switch between them
> would be non-constant, which creates a
On 01/08/2018 08:12 AM, Willy Tarreau wrote:
If a task has the TIF_NOPTI flag set, it doesn't want to experience
page table isolation. In this case, returns from kernel to user will
not switch the CR3, leaving it to the kernel one which already maps
both user and kernel pages. Upon entry in the k
On 01/08/2018 09:03 AM, Dave Hansen wrote:
On 01/08/2018 08:12 AM, Willy Tarreau wrote:
Since we're going to keep running on the same PGD when returning to
userspace for certain performance-critical tasks, we'll need the user
pages to be executable. So this code disables the extra protection
tha
> On Jan 8, 2018, at 5:15 PM, Andrew Cooper wrote:
>
>> On 09/01/2018 00:58, Linus Torvalds wrote:
>>> On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen wrote:
>>> Essentially the RSB are hidden registers, and the only way to clear them
>>> is the FILL_RETURN_BUFFER sequence. I don't see how clearing
On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote:
> On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote:
>> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote:
>> > I see and am not particularly against this, but what use case do you
>> > have in mind precisely ? I doubt
On Tue, Jan 9, 2018 at 1:25 PM, Shuah Khan wrote:
> On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote:
>> This tests that the vsyscall entries do what they're expected to do.
>> It also confirms that attempts to read the vsyscall page behave as
>> expected.
>&g
> On Jan 9, 2018, at 2:06 PM, Willy Tarreau wrote:
>
>> On Tue, Jan 09, 2018 at 10:46:02PM +0100, Borislav Petkov wrote:
>>> On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote:
>>> Requiring a reboot just to fix a performance problem you've discovered
>>> the hard way is not the most
> On Jan 9, 2018, at 5:03 PM, Andi Kleen wrote:
>
> This patch kit implements clearing of all unused registers on kernel entries,
> including system calls and all exceptions and interrupt.
>
> This doesn't fix any known issue, but will make it harder in general
> to exploit the kernel with spec
> On Jan 9, 2018, at 5:03 PM, Andi Kleen wrote:
>
> From: Andi Kleen
>
> Clear all registers on entering the 64bit kernel for exceptions and
> interrupts.
>
> Since there are no arguments this is fairly simple.
>
> Signed-off-by: Andi Kleen
> ---
> arch/x86/entry/entry_64.S | 5 +
> 1 f
> On Jan 9, 2018, at 5:03 PM, Andi Kleen wrote:
>
> From: Andi Kleen
>
> On a 32bit kernel clearing registers is much simpler than
> on 64bit. The arguments for syscalls are initially passed
> to a C function through the stack, so there's no need
> to figure out how many arguments to clear.
> On Jan 9, 2018, at 5:03 PM, Andi Kleen wrote:
>
> From: Andi Kleen
>
> In order to sanitize the system call arguments properly
> we need to know the number of syscall arguments for each
> syscall. Add a new column to the 32bit and 64bit syscall
> tables to list the number of arguments.
>
On Jan 9, 2018, at 5:34 PM, Andi Kleen wrote:
>> I don't like this at all. Once upon a time, Linux syscalls were supposed to
>> be fast. Then we learned about the Meltdown screwup, so we mostly fixed it
>> for real upstream and the distroa seriously half-arsed their own fixes [1].
>> This
> On Jan 9, 2018, at 5:47 PM, Thomas Gleixner wrote:
>
> On Wed, 10 Jan 2018, Van De Ven, Arjan wrote:
>>> In other words, if you use late microcode loading for getting IBRS, you
>>> don't get ALTERNATIVE patching and its benefits?
>>>
>>> I'll also profess some microcode ignorance here. Is "l
On Fri, Jan 12, 2018 at 10:33 PM, Willy Tarreau wrote:
> On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote:
>> In fact, it looks like this code is totally bogus and has never been
>> correct at all. Even in:
>>
>> commit 4b1d5ae3b103eda43f9d0f85c355bb
On Sat, Jan 13, 2018 at 12:45 PM, Thomas Gleixner wrote:
> On Sat, 13 Jan 2018, Andy Lutomirski wrote:
>> Trying to inventory this stuff scattered all over the place:
>>
>> #define PTI_PGTABLE_SWITCH_BITPAGE_SHIFT
>> #define PTI_SWITCH_PGTABLES_MASK(1<>
> On Jan 15, 2018, at 12:26 AM, Jon Masters wrote:
>
>> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote:
>> On Fri, 12 Jan 2018, Andi Kleen wrote:
Skylake still loses if it takes an SMI, right?
>>>
>>> SMMs are usually rare, especially on servers, and are usually
>>> not very p
> On Jan 14, 2018, at 12:13 PM, Nadav Amit wrote:
>
> Currently, when page-table isolation is on to prevent the Meltdown bug
> (CVE-2017-5754), CR3 is always loaded on system-call and interrupt.
>
> However, it appears that this is an unnecessary measure when programs
> run in compatibility mod
> On Jan 15, 2018, at 9:42 AM, Nadav Amit wrote:
>
> Andy Lutomirski wrote:
>
>>
>>> On Jan 14, 2018, at 12:13 PM, Nadav Amit wrote:
>>>
>>> Currently, when page-table isolation is on to prevent the Meltdown bug
>>> (CVE-2017-57
> On Jan 15, 2018, at 9:50 AM, Nadav Amit wrote:
>
> Andy Lutomirski wrote:
>
>>
>>
>>> On Jan 15, 2018, at 9:42 AM, Nadav Amit wrote:
>>>
>>> Andy Lutomirski wrote:
>>>
>>>>> On Jan 14, 2018, at 12:13 PM, Na
> On Jan 15, 2018, at 9:38 AM, Andrew Cooper wrote:
>
>> On 15/01/18 16:57, Andy Lutomirski wrote:
>>
>>>> On Jan 15, 2018, at 12:26 AM, Jon Masters wrote:
>>>>
>>>> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote:
>>&g
> On Jan 15, 2018, at 10:07 AM, David Woodhouse wrote:
>
>> On Mon, 2018-01-15 at 10:06 -0800, Andy Lutomirski wrote:
>>
>>> Refill or not, you are aware that a correctly timed SMI in a leaf
>>> function will cause the next ret to speculate into usersp
On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote:
> From: Alexei Starovoitov
> Date: Fri, 9 Mar 2018 10:50:49 -0800
>
>> On 3/9/18 10:23 AM, Andy Lutomirski wrote:
>>> It might not be totally crazy to back it by tmpfs.
>>
>> interesting. how do you
On Fri, Mar 9, 2018 at 7:38 PM, Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds
> wrote:
>>
>> How are you going to handle five processes doing the same setup concurrently?
>
> Side note: it's not just serialization. It's also "is it actually up
> and running".
>
I think
> On Mar 10, 2018, at 8:57 AM, French, Nicholas A. wrote:
>
>> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>>> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> On Thu, Mar 0
On Sat, Mar 10, 2018 at 1:43 AM, Alexei Starovoitov wrote:
> On 3/9/18 11:37 AM, Andy Lutomirski wrote:
>>
>> On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote:
>>>
>>> From: Alexei Starovoitov
>>> Date: Fri, 9 Mar 2018 10:50:49 -0800
>>
On Sun, Mar 11, 2018 at 10:55 AM, Dominik Brodowski
wrote:
> While at it, use SYSCALL_DEFINE3() instead of a hand-crafted syscall
> definition.
Great!
> static void complete_change_console(struct vc_data *vc);
> @@ -420,12 +420,12 @@ int vt_ioctl(struct tty_struct *tty,
>
On Sun, Mar 11, 2018 at 10:55 AM, Dominik Brodowski
wrote:
> The syscall entry points to the kernel defined by SYSCALL_DEFINEx()
> and COMPAT_SYSCALL_DEFINEx() should only be called from userspace
> through kernel entry points, but not from the kernel itself. This
> will allow cleanups and optimiz
> On Mar 11, 2018, at 12:51 PM, Nick French wrote:
>
> On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
>>>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just
>>>> a warning like "you have PAT enabled, so wc
On Mon, Mar 12, 2018 at 2:02 PM, Vitaly Kuznetsov wrote:
> vmx_save_host_state() is only called from kvm_arch_vcpu_ioctl_run() so
> the context is pretty well defined. Read MSR_FS_BASE from
> current->thread.fsbase after calling save_fsgs() which takes care of
> X86_BUG_NULL_SEG case now and will
irq_stack_union.
>
> Add new kernelmode_gs_base() API, irq_stack_union needs to be exported
> as KVM can be build as module.
>
Acked-by: Andy Lutomirski
On Mon, Mar 12, 2018 at 4:03 PM, Paolo Bonzini wrote:
> On 12/03/2018 15:02, Vitaly Kuznetsov wrote:
>>
>> +/*
>> + * Currently, the only way for processes to change their FS/GS base is to
>> call
>> + * ARCH_SET_FS/GS prctls and these reflect changes they make in
>> task->thread.
>> + * There a
On Mon, Mar 12, 2018 at 4:18 PM, Paolo Bonzini wrote:
> On 12/03/2018 17:13, Andy Lutomirski wrote:
>>>
>>> savesegment(fs, vmx->host_state.fs_sel);
>>> /*
>>> * When FSGSBASE extensions are enabled, this will have to use
>>
On Mon, Mar 12, 2018 at 4:42 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 7:50 AM, Kirill A. Shutemov
> wrote:
>>
>> I disagree that we should decide usefulness of the 5-level paging based on
>> size of physical memory on the machine.
>>
>> Consider use case when you have 100TiB database f
On Tue, Mar 6, 2018 at 1:34 AM, Alexei Starovoitov wrote:
> As the first step in development of bpfilter project [1] the request_module()
> code is extended to allow user mode helpers to be invoked. Idea is that
> user mode helpers are built as part of the kernel build and installed as
> tradition
On Tue, Mar 6, 2018 at 10:25 PM, Mickaël Salaün wrote:
>
>
> On 28/02/2018 00:09, Andy Lutomirski wrote:
>> On Tue, Feb 27, 2018 at 10:03 PM, Mickaël Salaün wrote:
>>>
>>> On 27/02/2018 05:36, Andy Lutomirski wrote:
>>>> On Tue, Feb 27, 2018
On Tue, Mar 6, 2018 at 11:06 PM, Mickaël Salaün wrote:
>
> On 06/03/2018 23:46, Tycho Andersen wrote:
>> On Tue, Mar 06, 2018 at 10:33:17PM +, Andy Lutomirski wrote:
>>>>> Suppose I'm writing a container manager. I want to run "mount" in the
>&
TIF_AUDIT_SYSCALL in case the number of populated audit rules is
> non-zero.
>
> Originally-by: Andy Lutomirski
> Signed-off-by: Jiri Kosina
> ---
>
> This is basically resurrection / rebase of patch Andi Lutomirski sent some
> time back in 2014 or so.
>
> Andi, is th
there are
no vsyscalls.
For all practical purposes, "native" was really just a chicken bit
in case something went wrong with the emulation. It's been over six
years, and nothing has gone wrong. Delete it.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig
On Wed, Mar 7, 2018 at 7:31 PM, Dominik Brodowski
wrote:
> On Wed, Mar 07, 2018 at 11:21:46AM -0800, Kees Cook wrote:
>> On Wed, Mar 7, 2018 at 11:12 AM, Andy Lutomirski wrote:
>> > Since Linux 3.2, vsyscalls have been deprecated and slow. From 3.2
>> > on, Lin
On Sun, Apr 8, 2018 at 6:13 AM, Mickaël Salaün wrote:
>
> On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
>>
>> On 27/02/2018 17:39, Andy Lutomirski wrote:
>>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
>>> wrote:
>>>> On Tue, Feb 27,
On Wed, Apr 11, 2018 at 1:33 PM, Greg KH wrote:
> On Wed, Apr 11, 2018 at 09:09:16PM +0100, David Howells wrote:
>> Greg KH wrote:
>>
>> > Why not just disable debugfs entirely? This half-hearted way to sorta
>> > lock it down is odd, it is meant to not be there at all, nothing in your
>> > norm
On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote:
>
> (*) CONFIG_LOCK_DOWN_KERNEL
>
> This makes lockdown available and applies it to all the points that
> need to be locked down if the mode is set. Lockdown mode can be
> enabled by providing:
>
> lockdown=1
By doing
On Thu, Apr 12, 2018 at 1:23 AM, Greg KH wrote:
> On Wed, Apr 11, 2018 at 07:54:12PM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 11, 2018 at 1:33 PM, Greg KH wrote:
>> > On Wed, Apr 11, 2018 at 09:09:16PM +0100, David Howells wrote:
>> >> Greg KH wrote:
>
On Mon, Mar 19, 2018 at 2:31 PM, Boris Ostrovsky
wrote:
> Writing to it directly does not work for Xen PV guests.
Whoops, my bad.
Acked-by: Andy Lutomirski
>
> Signed-off-by: Boris Ostrovsky
> ---
> arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
> 1 file changed, 1 insert
On Tue, Mar 20, 2018 at 8:26 AM, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
>> > Useful also for code that needs AVX-like registers to do things like CRCs.
>>
>> x86/crypto/ has a lot of AVX optimized code.
>
> Yeah, that's true, but the crypto code is processing fundamentally bigger
> bl
> 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 check on the current GS base is not
> sufficient. Fortuna
On Mon, Mar 19, 2018 at 5:49 PM, Chang S. Bae wrote:
> When FSGSBASE enabled, ptracer's FS/GS selector update
> fetches FS/GS base from GDT/LDT. This emulation of FS/GS
> segment loading provides backward compatibility for the
> legacy ptracers.
>
> When ptracer sets FS/GS selector, its base is go
On Mon, Mar 19, 2018 at 5:49 PM, Chang S. Bae wrote:
> FSGSBASE is 64-bit instruction set to allow read/write
> FS/GS base from any privilege. As introduced from
> Ivybridge, enabling effort has been revolving quite long
> [2,3,4] for various reasons. After extended discussions [1],
> this patchse
On Tue, Mar 20, 2018 at 3:05 PM, Andy Lutomirski wrote:
> On Mon, Mar 19, 2018 at 5:49 PM, Chang S. Bae
> wrote:
>> FSGSBASE is 64-bit instruction set to allow read/write
>> FS/GS base from any privilege. As introduced from
>> Ivybridge, enabling effort has been revolv
On Tue, Mar 20, 2018 at 8:07 PM, H. Peter Anvin wrote:
> On 03/20/18 03:16, David Laight wrote:
>> From: Chang S. Bae
>>> Sent: 19 March 2018 17:49
>> ...
>>> When FSGSBASE is enabled, SWAPGS needs if and only if (current)
>>> GS base is not the kernel's.
>>>
>>> FSGSBASE instructions allow user t
On Tue, Mar 20, 2018 at 3:10 PM, David Laight wrote:
> From: Andy Lutomirski
>> Sent: 20 March 2018 14:57
> ...
>> I'd rather see us finally finish the work that Rik started to rework
>> this differently. I'd like kernel_fpu_begin() to look like:
>>
>
On Tue, Mar 20, 2018 at 4:33 PM, Bae, Chang Seok
wrote:
> 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 f
On Tue, Mar 20, 2018 at 4:33 PM, Bae, Chang Seok
wrote:
> 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 ol
On Wed, Mar 21, 2018 at 6:32 AM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> And even if you ignore that "maintenance problems down the line" issue
>> ("we can fix them when they happen") I don't want to see games like
>> this, because I'm pretty sure it breaks the optimized xsave by tagg
On Wed, Mar 21, 2018 at 10:03 PM, H. Peter Anvin wrote:
> On 03/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
On Wed, Mar 21, 2018 at 7:01 AM, Metzger, Markus T
wrote:
>> -Original Message-
>> From: Andy Lutomirski [mailto:l...@kernel.org]
>> Sent: 21 March 2018 01:47
>
> Hello Andy,
>
>> I retract this particular comment. But I still think that all this
On Wed, Mar 21, 2018 at 3:11 PM, Bae, Chang Seok
wrote:
> 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_
On Thu, Mar 22, 2018 at 3:45 PM, Bae, Chang Seok
wrote:
> 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 c
On Thu, Mar 22, 2018 at 4:46 PM, Bae, Chang Seok
wrote:
>> 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 that your patch has exactly the same effect as the code in
my
1201 - 1300 of 10585 matches
Mail list logo
