Re: [Xen-devel] [PATCH 10/13] x86/alternative: Support indirect call replacement

On 10/04/17 08:58, Josh Poimboeuf wrote: > Add alternative patching support for replacing an instruction with an > indirect call. This will be needed for the paravirt alternatives. I have a patchset that generalizes the alternatives in what I think is a more robust way. I really, really want to

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 11:57, Kees Cook wrote: > On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin <h...@zytor.com> wrote: >> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64 >> has RIP-relative addressing there is no need for a dedicated PIC register. > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 09:32, Ingo Molnar wrote: > > BTW., I think things improved with ORC because with ORC we have RBP as an > extra > register and with PIE we lose RBX - so register pressure in code generation > is > lower. > We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:28, Peter Zijlstra wrote: > > Ah, I see, this is large mode and that needs to use MOVABS to load 64bit > immediates. Still, small RIP relative should be able to live at any > point as long as everything lives inside the same 2G relative range, so > would still allow the goal of

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:31, Peter Zijlstra wrote: > On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote: >> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > >>> Have you considered a kernel with -mcmodel=small (or medium) instead of >>> -fpie >>> -mcmodel=large? We can

Re: [Xen-devel] [RFC 06/22] kvm: Adapt assembly for PIE support

>,linux-pm <linux...@vger.kernel.org>,linux-arch <linux-a...@vger.kernel.org>,Linux-Sparse <linux-spa...@vger.kernel.org>,Kernel Hardening <kernel-harden...@lists.openwall.com> From: h...@zytor.com Message-ID: <83ba7600-bc8d-4c91-812c-dd2a0bf44.

Re: [Xen-devel] [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

lt;linux-a...@vger.kernel.org>,linux-spa...@vger.kernel.org,Kernel Hardening <kernel-harden...@lists.openwall.com> From: h...@zytor.com Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@zytor.com> On July 19, 2017 4:25:56 PM PDT, Thomas Garnier <thgar...@google.com> wrote: >On Wed

Re: [Xen-devel] [RFC 16/22] x86/percpu: Adapt percpu for PIE support

On 07/19/17 19:21, H. Peter Anvin wrote: > On 07/19/17 16:33, H. Peter Anvin wrote: >>> >>> I agree that it is odd but that's how the compiler generates code. I >>> will re-explore PIC options with mcmodel=small or medium, as mentioned >>> on other thr

Re: [Xen-devel] [RFC 16/22] x86/percpu: Adapt percpu for PIE support

On 07/19/17 16:33, H. Peter Anvin wrote: >> >> I agree that it is odd but that's how the compiler generates code. I >> will re-explore PIC options with mcmodel=small or medium, as mentioned >> on other threads. > > Why should the way compiler generates co

Re: [Xen-devel] [RFC 16/22] x86/percpu: Adapt percpu for PIE support

On 07/19/17 11:26, Thomas Garnier wrote: > On Tue, Jul 18, 2017 at 8:08 PM, Brian Gerst wrote: >> On Tue, Jul 18, 2017 at 6:33 PM, Thomas Garnier wrote: >>> Perpcu uses a clever design where the .percu ELF section has a virtual >>> address of zero and the

Re: [Xen-devel] [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

On 07/19/17 15:47, Thomas Garnier wrote: > On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <h...@zytor.com> wrote: >> On 07/18/17 15:33, Thomas Garnier wrote: >>> The x86 relocation tool generates a list of 32-bit signed integers. There >>> was no need to use 64-b

Re: [Xen-devel] [RFC 07/22] x86: relocate_kernel - Adapt assembly for PIE support

On 07/18/17 15:33, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > >

Re: [Xen-devel] [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

On 07/18/17 15:33, Thomas Garnier wrote: > The x86 relocation tool generates a list of 32-bit signed integers. There > was no need to use 64-bit integers because all addresses where above the 2G > top of the memory. > > This change add a large-reloc option to generate 64-bit unsigned integers. >

Re: [Xen-devel] [RFC 06/22] kvm: Adapt assembly for PIE support

On 07/19/17 08:40, Thomas Garnier wrote: >> >> This doesn't look right. It's accessing a per-cpu variable. The >> per-cpu section is an absolute, zero-based section and not subject to >> relocation. > > PIE does not respect the zero-based section, it tries to have > everything relative. Patch

Re: [Xen-devel] [RFC 21/22] x86/module: Add support for mcmodel large and PLTs

On 07/18/17 15:33, Thomas Garnier wrote: > With PIE support and KASLR extended range, the modules may be further > away from the kernel than before breaking mcmodel=kernel expectations. > > Add an option to build modules with mcmodel=large. The modules generated > code will make no assumptions on

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

,"Luis R . Rodriguez" ,Stanislaw Gruszka ,Peter Zijlstra ,Josh Poimboeuf ,Vitaly Kuznetsov ,Tim Chen ,Joerg Roedel

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

On 12/06/16 00:46, Jan Beulich wrote: >> + >> +#ifdef CONFIG_X86_32 >> +asm volatile ( >> +"pushfl\n\t" >> +"pushl %%cs\n\t" >> +"pushl $1f\n\t" >> +"iret\n\t" >> +"1:" >> +: "+r" (__sp) : : "cc", "memory"); > > I don't

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski wrote: >On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen >> wrote: >>> On 09/14/2016 02:01 PM, Kyle Huey wrote: > >>> Is

Re: [Xen-devel] [PATCH v1 7/7] tools: add userspace linker table sandbox

Vrabel ,Konrad Rzeszutek Wilk ,Michael Brown ,Juergen Gross ,Andrew Cooper ,Andy Shevchenko ,Paul Gortmaker

Re: [Xen-devel] [PATCH v1 0/7] tools: add linker table userspace sandbox

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

Re: [Xen-devel] [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote: > Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c > Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c > Author: Jan Beulich > AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600 > Committer:

Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?

On 04/04/16 11:24, Luis R. Rodriguez wrote: > On Mon, Apr 04, 2016 at 09:01:06AM -0700, H. Peter Anvin wrote: >> On 03/31/16 13:03, Luis R. Rodriguez wrote: >>> Andy S, Peter, Thomas, Jiang (or who might know), >>> >>> Do Intel MID platforms exist wit

Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?

On 03/31/16 13:03, Luis R. Rodriguez wrote: > Andy S, Peter, Thomas, Jiang (or who might know), > > Do Intel MID platforms exist with PNP BIOS support? What abot CE4100? > As it stands I don't see anything that would prevent this but I would > suspect a possibility might be that it doesn't. I'm

Re: [Xen-devel] [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/16 13:06, Luis R. Rodriguez wrote: >> >> I think the \n\t is unnecessary. > > Super! I wonder if we we can just use this on s390 as well without it pooping? > I ask as this would set a precedent. > Ask Heike, but I think just ; or \n ought be be fine. I do not know of *any* case where

Re: [Xen-devel] [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > +/** > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if > any > + * > + * @tbl: linker table > + * @func: structure name for the function name we want to call. > + * @args...: arguments to pass to func > + * > + *

Re: [Xen-devel] [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > + > +/** > + * DOC: Regular linker linker table constructors > + * > + * Regular constructors are expected to be used for valid linker table > entries. > + * Valid uses of weak entries other than the beginning and is currently > + * untested but

Re: [Xen-devel] [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > With a generic linker tables solution in place we > need a general asm solution for declaring entries > with asm. The first easy target is to cover the C > asm declarations, guard the header file for now > and define a first generic entry

Re: [Xen-devel] [RFC v2 0/7] linux: add linker tables

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > This is my v2 of the original linker table work [0], now with > six proof of concepts ports of existing code using custom section > with custom linker script modifications: > > * DEFINE_LINKTABLE_TEXT(char, kprobes); > *

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 01/22/2016 05:44 AM, Michael Matz wrote: > Hi, > > On Thu, 21 Jan 2016, H. Peter Anvin wrote: > >> Something that confuses me is that gcc seems to give these sections the >> "aw" attributes which makes as complain. This might be a gcc bug. > > Workar

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote: >> >> Should it be possible to resuse free_init_pages() and/or >> free_reserved_area() only for routines (members in the array in this >> case of a struct of fns) that don't meet our subarch once we're done >> iterating over the routies and know we

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/25/16 13:12, Luis R. Rodriguez wrote: >> >> Perhaps, but someone would still have to set hardware_subarch. And >> it's hvmlite_bootparams() that does it. > > No, Xen would do it as well, essentially all of hvmlite_bootparams() could be > done in Xen. > Or a stub code. -hpa

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk wrote: > >>However, this stub belongs in Linux, not in the Xen toolstack. That >>way, when the Linux boot protocol is modified, both sides can be >>updated >>accordingly. > >I would add that this idea is borrowed

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On January 23, 2016 8:12:23 AM PST, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: >On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" <h...@zytor.com> >wrote: >>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk >><konrad.w...@or

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 01/22/2016 05:44 AM, Michael Matz wrote: > Hi, > > On Thu, 21 Jan 2016, H. Peter Anvin wrote: > >> Something that confuses me is that gcc seems to give these sections the >> "aw" attributes which makes as complain. This might be a gcc bug. > > Workar

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 11:46, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin <h...@zytor.com> wrote: >>> And that's exactly what HVMlite does. Most of this shim layer is setting >>> up boot_params, after which we jump to standard x86 boot pa

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 12/17/15 20:40, H. Peter Anvin wrote: >> >> const struct >> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0]; >> >> const struct >> foo__attribute__((used,section(".rodata.tbl.tablename.999"))) >> tablena

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 01/21/16 14:25, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk > wrote: >>> Sure, do we know if that ICC compatible? Do we care? There are a >>> series of ICC hacks put in place on ipxe's original solution which >>> I've folded in, it

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 12:05, Luis R. Rodriguez wrote: > >> At least on i386, >> we have to do this in assembly code. > > Neat! How is that order kept? > Right now subarch_entries[] is just an array indexed by subarch number hardcoded in head_32.S. However, if you have a list of (id, target) then you

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 16:25, Luis R. Rodriguez wrote: >> >> Basically, if the hardware is enumerable using standard PC mechanisms (PCI, >> ACPI) and doesn't need a special boot flow it should use type 0. > > I can extend the documentation as part of this to be clear. > > I will note though that this

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 05:45, Boris Ostrovsky wrote: >> I don't think the hypervisor should be setting Linux specific boot >> related parameters, the boot ABI should be OS agnostic. IMHO, a small >> shim should be added to Linux in order to set what Linux requires when >> entering from a Xen entry point.

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 11:50, H. Peter Anvin wrote: > > Right... we already do that. > > I don't even think you need to initialize any tables. At least on i386, > we have to do this in assembly code. However, it is just a simple table > walk. :) > It might make more sense to make

Re: [Xen-devel] [RFC v1 2/8] tables.h: add linker table support

On January 20, 2016 3:15:48 PM PST, Michael Brown wrote: >>> + * To solve this problem linker tables can be used on Linux, it >enables you to >>> + * always force compiling of select features that one wishes to >avoid bit-rot >>> + * while still enabling you to disable linking

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On 01/20/16 13:33, Luis R. Rodriguez wrote: > > That's correct for PV and PVH, likewise when qemu is required for HVM > qemu could set it. I have the qemu change done but that should only > cover HVM. A common place to set this as well could be the hypervisor, > but currently the hypervisor

Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support

On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" <mcg...@do-not-panic.com> wrote: >On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin <h...@zytor.com> wrote: >> On 01/20/16 13:33, Luis R. Rodriguez wrote: >>> >>> That's correct for PV and PVH,

Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early

On January 15, 2016 4:43:04 PM PST, "Luis R. Rodriguez" wrote: >On Fri, Jan 15, 2016 at 03:47:25PM -0800, Andy Lutomirski wrote: >> On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez >wrote: >> > I will be respinning the generic Linux linker table solution [0]

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

I think we can make this even more generic. In particular, I would love to see a solution for link tables that: a) can be used for any kind of data structures, not just function pointers (the latter is a specialization of the former); b) doesn't need any changes to the linker scripts once the

Re: [Xen-devel] [RFC v1 5/8] x86/init: move ebda reservations into linker table

On 12/17/15 12:48, Andy Lutomirski wrote: > > I'm entirely ignorant of anything going on in gPXE/iPXE. > > Can you explain what a linker table *does*? It looks like all you've > done in this patch is to move code around. What actually happens? > A linker table is a data structure that is

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 12/17/15 15:46, Luis R. Rodriguez wrote: > > I explain why I do that there but the gist of it is that on Linux we may also > want stronger semantics for specific linker table solutions, and solutions > such > as those devised on the IOMMU init stuff do memmove() for sorting depending on >

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 12/17/15 20:25, H. Peter Anvin wrote: > > /* DECLARE_LINKTABLE_RO */ > extern const struct foo tablename[], tablename__end[]; > > /* DEFINE_LINKTABLE_RO */ > DECLARE_LINKTABLE_RO(struct foo, tablename); > > const struct > foo__attribute__((used,section(".roda

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On December 15, 2015 2:16:29 PM PST, "Luis R. Rodriguez" wrote: >From: "Luis R. Rodriguez" > > A long time ago in a galaxy far, > far away... > >Konrad Rzeszutek Wilk posted patches which eventually got merged to >help >with

Re: [Xen-devel] [PATCH] x86/mm: Skip the hypervisor range when walking PGD

On 11/05/15 10:56, Boris Ostrovsky wrote: > The range between 0x8000 and 0x87ff is reserved > for hypervisor and therefore we should not try to follow PGD's indexes > corresponding to those addresses. > > While this has alsways been a problem, with commit e1a58320a38d

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 09/21/2015 09:36 AM, Linus Torvalds wrote: > > How many msr reads are so critical that the function call > overhead would matter? Get rid of the inline version of the _safe() > thing too, and put that thing there too. > Probably only the ones that may go in the context switch path.

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

However, the difference between one CONFIG and another is quite frankly crazy. We should explicitly use the safe versions where this is appropriate, and then yes, we should do this. Yet another reason the paravirt code is batshit crazy. On September 17, 2015 2:31:34 AM PDT, Borislav Petkov

Re: [Xen-devel] [PATCH v5 2/4] x86/ldt: Make modify_ldt synchronous

On 07/27/2015 10:29 PM, Andy Lutomirski wrote: modify_ldt has questionable locking and does not synchronize threads. Improve it: redesign the locking and synchronize all threads' LDTs using an IPI on all modifications. This will dramatically slow down modify_ldt in multithreaded programs,

Re: [Xen-devel] [PATCH 0/8] Use correctly the Xen memory terminologies in Linux

On 07/28/2015 08:02 AM, Julien Grall wrote: Hi all, This patch series aims to use the memory terminologies described in include/linux/mm.h [1] for Linux xen code. Linux is using mistakenly MFN when GFN is meant, I suspect this is because the first support of Xen was for PV. This has

Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments

On 06/04/2015 12:55 PM, Rusty Russell wrote: Yeah, hard cases make bad law. I'm not too unhappy with this fix; ideally we'd rename save_fl and restore_fl to save_eflags_if and restore_eflags_if too. I would be fine with this... but please document what the bloody semantics of pvops is

Re: [Xen-devel] [PATCH] x86/cpu: Fix SMAP check in PVOPS environments

On 06/03/2015 02:31 AM, Andrew Cooper wrote: There appears to be no formal statement of what pv_irq_ops.save_fl() is supposed to return precisely. Native returns the full flags, while lguest and Xen only return the Interrupt Flag, and both have comments by the implementations stating that

Re: [Xen-devel] [PATCHv1] x86: don't schedule when handling #NM exception

On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote: On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote: On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote: The following patch does the always eager allocation. It's a fixup of Suresh's original patch. Hey Peter, I think

Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to be preempted

On 12/10/2014 03:34 PM, Luis R. Rodriguez wrote: diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 344b63f..40b5c0c 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback) ENTRY(xen_do_upcall) 1: