Re: [RFC][PATCH] objtool: STAC/CLAC validation

On February 22, 2019 2:26:35 PM PST, Peter Zijlstra wrote: >On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote: > >> But correct :) > >> I agree, that a function which is doing the actual copy should be >callable, >> but random other functions? NO! > >So find the below patch --

Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch

On February 19, 2019 1:04:09 AM PST, Peter Zijlstra wrote: >On Mon, Feb 18, 2019 at 02:30:21PM -0800, H. Peter Anvin wrote: >> On 2/16/19 2:30 AM, Peter Zijlstra wrote: >> > On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote: >> >> This implies we invoke schedule -- a restricted

Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch

On February 14, 2019 2:14:29 AM PST, Peter Zijlstra wrote: >On Wed, Feb 13, 2019 at 02:49:47PM -0800, Andy Lutomirski wrote: > >> Do we need to backport this thing? > >Possibly, just to be safe. > >> The problem can’t be too widespread or we would have heard of it >before. > >Yes, so far we've

Re: [PATCH v5 01/13] taint: Introduce a new taint flag (insecure)

On February 5, 2019 2:46:11 PM PST, Randy Dunlap wrote: >On 2/5/19 1:21 PM, Andrew Morton wrote: >> On Fri, 1 Feb 2019 18:42:29 -0800 Andy Lutomirski >wrote: >> >>> On Fri, Feb 1, 2019 at 12:54 PM Chang S. Bae > wrote: For testing (or root-only) purposes, the new flag will serve to

Re: [PATCH v5 00/13] x86: Enable FSGSBASE instructions

On February 1, 2019 6:43:25 PM PST, Andy Lutomirski wrote: >Hi hpa- > >A while back, you were working on some patches to make modify_ldt() >play better with this series. What happened to them? > >--Andy Looks like I need to dig them out... -- Sent from my Android device wit

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 25, 2019 11:15:52 AM PST, Daniel Colascione wrote: >On Fri, Jan 25, 2019 at 11:01 AM wrote: >> >> On January 24, 2019 12:59:29 PM PST, Joel Fernandes > wrote: >> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote: >> >> >> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 24, 2019 12:59:29 PM PST, Joel Fernandes wrote: >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote: >> >> On 1/23/19 11:37 PM, Daniel Colascione wrote: >[..] >> > > Personally I advocated a more aggressive approach with Joel in >private: >> > > just put the darn headers

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 20, 2019 8:10:03 AM PST, Joel Fernandes wrote: >On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote: >> On January 19, 2019 2:36:06 AM PST, Greg KH > wrote: >> >On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote: >> >> This seems like a pretty horrible idea

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 20, 2019 5:45:53 PM PST, Joel Fernandes wrote: >On Sun, Jan 20, 2019 at 01:58:15PM -0800, h...@zytor.com wrote: >> On January 20, 2019 8:10:03 AM PST, Joel Fernandes > wrote: >> >On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote: >> >> On January 19, 2019 2:36:06 AM PST,

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 19, 2019 2:36:06 AM PST, Greg KH wrote: >On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote: >> This seems like a pretty horrible idea and waste of kernel memory. > >It's only a waste if you want it to be a waste, i.e. if you load the >kernel module. > >This really isn't

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

On January 19, 2019 3:25:03 PM PST, Joel Fernandes wrote: >On Sat, Jan 19, 2019 at 12:43:35PM -0500, Daniel Colascione wrote: >> On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes > wrote: >> > >> > On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote: >> > > On Fri, Jan 18, 2019 at 05:55:43PM

Re: [PATCH 01/17] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"

On January 17, 2019 2:39:15 PM PST, Nadav Amit wrote: >> On Jan 17, 2019, at 1:15 PM, h...@zytor.com wrote: >> >> On January 16, 2019 10:47:01 PM PST, Masami Hiramatsu > wrote: >>> On Wed, 16 Jan 2019 16:32:43 -0800 >>> Rick Edgecombe wrote: >>> From: Nadav Amit text_mutex is

Re: [PATCH 06/17] x86/alternative: use temporary mm for text poking

On January 17, 2019 1:43:54 PM PST, Nadav Amit wrote: >> On Jan 17, 2019, at 12:47 PM, Andy Lutomirski >wrote: >> >> On Thu, Jan 17, 2019 at 12:27 PM Andy Lutomirski >wrote: >>> On Wed, Jan 16, 2019 at 4:33 PM Rick Edgecombe >>> wrote: From: Nadav Amit text_poke() can

Re: [PATCH 01/17] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"

On January 16, 2019 10:47:01 PM PST, Masami Hiramatsu wrote: >On Wed, 16 Jan 2019 16:32:43 -0800 >Rick Edgecombe wrote: > >> From: Nadav Amit >> >> text_mutex is currently expected to be held before text_poke() is >> called, but we kgdb does not take the mutex, and instead *supposedly* >>

Re: [PATCH v3 0/6] Static calls

On January 14, 2019 3:27:55 PM PST, Andy Lutomirski wrote: >On Mon, Jan 14, 2019 at 2:01 PM H. Peter Anvin wrote: >> >> So I was already in the middle of composing this message when Andy >posted: >> >> > I don't even think this is sufficient. I think we also need >everyone >> > who clears the

Re: [PATCH v3 0/6] Static calls

On January 11, 2019 11:34:34 AM PST, Linus Torvalds wrote: >On Fri, Jan 11, 2019 at 11:24 AM wrote: >> >> I still don't see why can't simply spin in the #BP handler until the >patch is complete. > >So here's at least one problem: > >text_poke_bp() > text_poke(addr, , sizeof(int3)); >

Re: [PATCH v3 0/6] Static calls

On January 11, 2019 11:34:34 AM PST, Linus Torvalds wrote: >On Fri, Jan 11, 2019 at 11:24 AM wrote: >> >> I still don't see why can't simply spin in the #BP handler until the >patch is complete. > >So here's at least one problem: > >text_poke_bp() > text_poke(addr, , sizeof(int3)); >

Re: [PATCH v3 0/6] Static calls

On January 11, 2019 11:03:30 AM PST, Linus Torvalds wrote: >On Fri, Jan 11, 2019 at 7:15 AM Josh Poimboeuf >wrote: >> >> > >> > Now, in the int3 handler can you take the faulting RIP and search >for it in >> > the “static-calls” table, writing the RIP+5 (offset) into R10 >(return >> > address)

Re: [PATCH v3 5/6] x86/alternative: Use a single access in text_poke() where possible

On January 10, 2019 5:34:21 PM PST, Sean Christopherson wrote: >On Thu, Jan 10, 2019 at 04:59:55PM -0800, h...@zytor.com wrote: >> On January 10, 2019 9:42:57 AM PST, Sean Christopherson > wrote: >> >On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote: >> >> On Thu, 10 Jan 2019

Re: [PATCH v3 5/6] x86/alternative: Use a single access in text_poke() where possible

On January 10, 2019 9:42:57 AM PST, Sean Christopherson wrote: >On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote: >> On Thu, 10 Jan 2019 11:20:04 -0600 >> Josh Poimboeuf wrote: >> >> >> > > While I can't find a reason for hypervisors to emulate this >instruction, >> > > smarter

Re: [PATCH] x86/boot: drop memset from copy.S

On January 7, 2019 12:52:57 AM PST, Cao jin wrote: >Hi, > >On 1/7/19 3:59 PM, h...@zytor.com wrote: >> On January 6, 2019 11:40:56 PM PST, Cao jin > wrote: >>> According to objdump output of setup, function memset is not used in >>> setup code. Currently, all usage of memset in setup come from

Re: [PATCH] x86/boot: drop memset from copy.S

On January 6, 2019 11:40:56 PM PST, Cao jin wrote: >According to objdump output of setup, function memset is not used in >setup code. Currently, all usage of memset in setup come from macro >definition of string.h. > >Signed-off-by: Cao jin >--- >Compiled and booted under x86_64; compiled under

Re: [RFC v2 1/6] x86: introduce kernel restartable sequence

On December 30, 2018 11:21:07 PM PST, Nadav Amit wrote: >It is sometimes beneficial to have a restartable sequence - very few >instructions which if they are preempted jump to a predefined point. > >To provide such functionality on x86-64, we use an empty REX-prefix >(opcode 0x40) as an

Re: Can we drop upstream Linux x32 support?

On December 10, 2018 5:40:33 PM PST, Linus Torvalds wrote: >On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski >wrote: >> >> I'm seriously considering sending a patch to remove x32 support from >> upstream Linux. Here are some problems with it: > >I talked to Arnd (I think - we were talking about

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

On December 3, 2018 2:38:11 AM PST, Juergen Gross wrote: >In case a broken boot loader doesn't clear its struct boot_params clear >rsdp_addr in sanitize_boot_params(). > >This fixes commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP >address from boot params if available") e.g. for the case of

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

On December 3, 2018 2:38:11 AM PST, Juergen Gross wrote: >In case a broken boot loader doesn't clear its struct boot_params clear >rsdp_addr in sanitize_boot_params(). > >This fixes commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP >address from boot params if available") e.g. for the case of

Re: [PATCH] x86/TSC: Use RDTSCP

On November 23, 2018 12:03:07 PM PST, Guenter Roeck wrote: >Hi, > >On Mon, Nov 19, 2018 at 07:45:56PM +0100, Borislav Petkov wrote: >> From: Borislav Petkov >> >> Currently, the kernel uses >> >> [LM]FENCE; RDTSC >> >> in the timekeeping code, to guarantee monotonicity of time where the >>

Re: [PATCH] x86/TSC: Use RDTSCP

On November 23, 2018 12:03:07 PM PST, Guenter Roeck wrote: >Hi, > >On Mon, Nov 19, 2018 at 07:45:56PM +0100, Borislav Petkov wrote: >> From: Borislav Petkov >> >> Currently, the kernel uses >> >> [LM]FENCE; RDTSC >> >> in the timekeeping code, to guarantee monotonicity of time where the >>

Re: Sleeping in user_access section

On November 23, 2018 1:27:02 AM PST, Julien Thierry wrote: >Hi, > >I made an attempt at implementing the >user_access_begin()/user_access_end() macros along with the >get/put_user_unsafe() for arm64 by toggling the status of PAN (more or >less similar to x86's STAC/CTAC). > >With a small

Re: Sleeping in user_access section

On November 23, 2018 1:27:02 AM PST, Julien Thierry wrote: >Hi, > >I made an attempt at implementing the >user_access_begin()/user_access_end() macros along with the >get/put_user_unsafe() for arm64 by toggling the status of PAN (more or >less similar to x86's STAC/CTAC). > >With a small

Re: [PATCH] x86/TSC: Use RDTSCP

ou mean RDTSCP. :) > >Also in the sense that you have a single instruction which gives you >that barrier of waiting for all older insns to retire before reading >the >TSC vs two where you don't necessarily know what happens on the uarch >level. I mean, nothing probably happens but RDTSCP is

Re: [PATCH] x86/TSC: Use RDTSCP

ou mean RDTSCP. :) > >Also in the sense that you have a single instruction which gives you >that barrier of waiting for all older insns to retire before reading >the >TSC vs two where you don't necessarily know what happens on the uarch >level. I mean, nothing probably happens but RDTSCP is

Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

On November 10, 2018 7:22:29 AM PST, Juergen Gross wrote: >On 09/11/2018 23:23, H. Peter Anvin wrote: >> I just noticed this patch -- I missed it because the cover message >> seemed far more harmless so I didn't notice this change. >> >> THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY

Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

On November 10, 2018 7:22:29 AM PST, Juergen Gross wrote: >On 09/11/2018 23:23, H. Peter Anvin wrote: >> I just noticed this patch -- I missed it because the cover message >> seemed far more harmless so I didn't notice this change. >> >> THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY

Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline asm

On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe wrote: > > >On 2018-11-07 11:56 a.m., Nadav Amit wrote: >> HPA indicated more than once that this is wrong (and that was indeed >my >> initial solution), since it is not guaranteed that the compiler would >put >&

Re: [PATCH v9 02/10] Makefile: Prepare for using macros for inline asm

On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe wrote: > > >On 2018-11-07 11:56 a.m., Nadav Amit wrote: >> HPA indicated more than once that this is wrong (and that was indeed >my >> initial solution), since it is not guaranteed that the compiler would >put >&

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

e reason this patch is labeled RFC is while I can verify >that this >> > > > >> fixes the issue, I'm not entirely sure why the '-Wa,-' works >for GCC >> > > > >> and not Clang. I looked into what the flag means and I >couldn't really >> > &

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

e reason this patch is labeled RFC is while I can verify >that this >> > > > >> fixes the issue, I'm not entirely sure why the '-Wa,-' works >for GCC >> > > > >> and not Clang. I looked into what the flag means and I >couldn't really >> > &

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

ind anything so I just assume it's taking input from stdin? The >issue >> >> could stem from how GCC forks gas versus how Clang does it. If >this >> >> isn't of concern and the maintainers are happy with this patch as >is, >> >> feel free to take it. >>

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

ind anything so I just assume it's taking input from stdin? The >issue >> >> could stem from how GCC forks gas versus how Clang does it. If >this >> >> isn't of concern and the maintainers are happy with this patch as >is, >> >> feel free to take it. >>

Re: [PATCH stable v2 1/2] termios, tty/tty_baudrate.c: fix buffer overrun

On October 23, 2018 7:53:51 AM PDT, Greg Kroah-Hartman wrote: >On Mon, Oct 22, 2018 at 09:19:04AM -0700, H. Peter Anvin (Intel) wrote: >> From: "H. Peter Anvin" >> >> On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in >tty_baudrate.c does >> not do any limit checking on the

Re: [PATCH stable v2 1/2] termios, tty/tty_baudrate.c: fix buffer overrun

On October 23, 2018 7:53:51 AM PDT, Greg Kroah-Hartman wrote: >On Mon, Oct 22, 2018 at 09:19:04AM -0700, H. Peter Anvin (Intel) wrote: >> From: "H. Peter Anvin" >> >> On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in >tty_baudrate.c does >> not do any limit checking on the

Re: Insanely high baud rates

On October 11, 2018 5:31:34 AM PDT, Alan Cox wrote: >> I'm mostly wondering if it is worth future-proofing for new >transports. It sounds like we can have a consensus on leaving the upper >4 bits of the speed fields reserved, but leave the details of >implementation for the future? > >It seems

Re: Insanely high baud rates

On October 11, 2018 5:31:34 AM PDT, Alan Cox wrote: >> I'm mostly wondering if it is worth future-proofing for new >transports. It sounds like we can have a consensus on leaving the upper >4 bits of the speed fields reserved, but leave the details of >implementation for the future? > >It seems

Re: Insanely high baud rates

On October 10, 2018 1:17:17 PM PDT, Alan Cox wrote: >On Tue, 9 Oct 2018 12:19:04 -0700 >"H. Peter Anvin" wrote: > >> [Resending to a wider audience] >> >> In trying to get the termios2 interface actually implemented in >glibc, >> the question came up if we will ever care about baud rates in

Re: Insanely high baud rates

On October 10, 2018 1:17:17 PM PDT, Alan Cox wrote: >On Tue, 9 Oct 2018 12:19:04 -0700 >"H. Peter Anvin" wrote: > >> [Resending to a wider audience] >> >> In trying to get the termios2 interface actually implemented in >glibc, >> the question came up if we will ever care about baud rates in

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

On October 4, 2018 2:12:22 AM PDT, Ingo Molnar wrote: > >* Nadav Amit wrote: > >> I can run some tests. (@hpa: I thought you asked about the -pipe >overhead; >> perhaps I misunderstood). > >Well, tests are unlikely to show the overhead of extra lines of thi

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

On October 4, 2018 2:12:22 AM PDT, Ingo Molnar wrote: > >* Nadav Amit wrote: > >> I can run some tests. (@hpa: I thought you asked about the -pipe >overhead; >> perhaps I misunderstood). > >Well, tests are unlikely to show the overhead of extra lines of thi

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

source >code >>> away >>> from where it's used. >>> >>> Thanks, >>> >>> Ingo >> >> It's not just for working around a stupid GCC bug, but it also has a >huge >> potential for cleaning up the inline asm in gener

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

source >code >>> away >>> from where it's used. >>> >>> Thanks, >>> >>> Ingo >> >> It's not just for working around a stupid GCC bug, but it also has a >huge >> potential for cleaning up the inline asm in gener

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote: > >* Ingo Molnar wrote: > >> I'm also somewhat annoyed at the fact that this series carries a >boatload >> of reviewed-by's and acked-by's, yet none of those reviewers found it >> important to point out the large chasm that is gaping between

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote: > >* Ingo Molnar wrote: > >> I'm also somewhat annoyed at the fact that this series carries a >boatload >> of reviewed-by's and acked-by's, yet none of those reviewers found it >> important to point out the large chasm that is gaping between

Re: [PATCH v8 02/10] Makefile: Prepare for using macros for inline asm

On October 2, 2018 3:59:52 AM PDT, Ingo Molnar wrote: > >* Nadav Amit wrote: > >> at 1:58 AM, Rasmus Villemoes wrote: >> >> > On 2018-09-18 23:28, Nadav Amit wrote: >> > >> >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile >> >> index 8f6e7eb8ae9f..944fa3bc9376 100644 >> >> ---

Re: [PATCH v8 02/10] Makefile: Prepare for using macros for inline asm

On October 2, 2018 3:59:52 AM PDT, Ingo Molnar wrote: > >* Nadav Amit wrote: > >> at 1:58 AM, Rasmus Villemoes wrote: >> >> > On 2018-09-18 23:28, Nadav Amit wrote: >> > >> >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile >> >> index 8f6e7eb8ae9f..944fa3bc9376 100644 >> >> ---

Re: [PATCH v12 05/13] x86/sgx: architectural structures

On July 5, 2018 1:09:12 PM PDT, Jarkko Sakkinen wrote: >On Thu, Jul 05, 2018 at 08:31:42AM -0700, Dave Hansen wrote: >> On 07/03/2018 11:19 AM, Jarkko Sakkinen wrote: >> > +struct sgx_secs { >> > + uint64_t size; >> > + uint64_t base; >> > + uint32_t ssaframesize; >> > + uint32_t miscselect;

Re: [PATCH v12 05/13] x86/sgx: architectural structures

On July 5, 2018 1:09:12 PM PDT, Jarkko Sakkinen wrote: >On Thu, Jul 05, 2018 at 08:31:42AM -0700, Dave Hansen wrote: >> On 07/03/2018 11:19 AM, Jarkko Sakkinen wrote: >> > +struct sgx_secs { >> > + uint64_t size; >> > + uint64_t base; >> > + uint32_t ssaframesize; >> > + uint32_t miscselect;

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 28, 2018 1:33:24 PM PDT, Andy Lutomirski wrote: >On Wed, Jun 27, 2018 at 11:22 AM, wrote: >> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski >wrote: >>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski > >>>wrote: > On Jun 22, 2018, at 11:29 AM, H. Peter Anvin >>>

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 28, 2018 1:33:24 PM PDT, Andy Lutomirski wrote: >On Wed, Jun 27, 2018 at 11:22 AM, wrote: >> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski >wrote: >>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski > >>>wrote: > On Jun 22, 2018, at 11:29 AM, H. Peter Anvin >>>

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 27, 2018 11:22:14 AM PDT, h...@zytor.com wrote: >On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski >wrote: >>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski > >>wrote: >>> >>> >>> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin >> wrote: > On 06/22/18 07:24, Andy Lutomirski

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 27, 2018 11:22:14 AM PDT, h...@zytor.com wrote: >On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski >wrote: >>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski > >>wrote: >>> >>> >>> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin >> wrote: > On 06/22/18 07:24, Andy Lutomirski

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski wrote: >On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski >wrote: >> >> >> >>> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin > wrote: >>> On 06/22/18 07:24, Andy Lutomirski wrote: That RPL3 part is false. The following program

Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments()

On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski wrote: >On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski >wrote: >> >> >> >>> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin > wrote: >>> On 06/22/18 07:24, Andy Lutomirski wrote: That RPL3 part is false. The following program

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

On June 25, 2018 9:33:35 AM PDT, Randy Dunlap wrote: >On 06/25/2018 03:25 AM, Jan Beulich wrote: >> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use >> 32-bit ones instead. > >Hmph. Is that considered a bug (errata)? > >URL/references? > >Are these changes really only zeroing

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

On June 25, 2018 9:33:35 AM PDT, Randy Dunlap wrote: >On 06/25/2018 03:25 AM, Jan Beulich wrote: >> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use >> 32-bit ones instead. > >Hmph. Is that considered a bug (errata)? > >URL/references? > >Are these changes really only zeroing

Re: [PATCH v3 7/7] x86/ldt,ptrace: provide regset access to the LDT

On June 22, 2018 7:49:13 AM PDT, Andy Lutomirski wrote: >On Thu, Jun 21, 2018 at 2:18 PM H. Peter Anvin, Intel > wrote: >> >> From: "H. Peter Anvin" >> >> Provide ptrace/regset access to the LDT, if one exists. This >> interface provides both read and write access. The write code is >> unified

Re: [PATCH v3 7/7] x86/ldt,ptrace: provide regset access to the LDT

On June 22, 2018 7:49:13 AM PDT, Andy Lutomirski wrote: >On Thu, Jun 21, 2018 at 2:18 PM H. Peter Anvin, Intel > wrote: >> >> From: "H. Peter Anvin" >> >> Provide ptrace/regset access to the LDT, if one exists. This >> interface provides both read and write access. The write code is >> unified

Re: [PATCH v3 0/7] x86/ptrace: regset access to the GDT and LDT

On June 21, 2018 6:58:51 PM PDT, Ingo Molnar wrote: > >* H. Peter Anvin, Intel wrote: > >> From: "H. Peter Anvin" >> >> Give a debugger access to the visible part of the GDT and LDT. This >> allows a debugger to find out what a particular segment descriptor >> corresponds to; e.g. if %cs is

Re: [PATCH v3 0/7] x86/ptrace: regset access to the GDT and LDT

On June 21, 2018 6:58:51 PM PDT, Ingo Molnar wrote: > >* H. Peter Anvin, Intel wrote: > >> From: "H. Peter Anvin" >> >> Give a debugger access to the visible part of the GDT and LDT. This >> allows a debugger to find out what a particular segment descriptor >> corresponds to; e.g. if %cs is

Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly

On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote: >Use assembly macros for jump-labels and call them from inline assembly. >This not only makes the code more readable, but also improves >compilation decision, specifically inline decisions which GCC base on >the number of new lines in inline

Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly

On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote: >Use assembly macros for jump-labels and call them from inline assembly. >This not only makes the code more readable, but also improves >compilation decision, specifically inline decisions which GCC base on >the number of new lines in inline

Re: [PATCH v2 7/8] x86/segments/32: Introduce CPU_NUMBER segment

On June 6, 2018 12:07:15 PM PDT, Brian Gerst wrote: >On Wed, Jun 6, 2018 at 1:16 PM, Andy Lutomirski >wrote: >> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae > wrote: >>> >>> The new entry will be equivalent to that of x86-64 which >>> stores CPU number. The entry is placed in segment 23 in GDT

Re: [PATCH v2 7/8] x86/segments/32: Introduce CPU_NUMBER segment

On June 6, 2018 12:07:15 PM PDT, Brian Gerst wrote: >On Wed, Jun 6, 2018 at 1:16 PM, Andy Lutomirski >wrote: >> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae > wrote: >>> >>> The new entry will be equivalent to that of x86-64 which >>> stores CPU number. The entry is placed in segment 23 in GDT

Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" wrote: >I found that glibc has already dealt with this case. So this issue must >have been met before, should it be maintained by libc/user? > > if (GLRO(dl_sysinfo_dso) == NULL) > { > kact.sa_flags |= SA_RESTORER;

Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" wrote: >I found that glibc has already dealt with this case. So this issue must >have been met before, should it be maintained by libc/user? > > if (GLRO(dl_sysinfo_dso) == NULL) > { > kact.sa_flags |= SA_RESTORER;

Re: [PATCH V2 06/15] taint: Add taint for insecure

On May 31, 2018 1:25:39 PM PDT, Andy Lutomirski wrote: >On Thu, May 31, 2018 at 10:58 AM Chang S. Bae > wrote: >> >> When adding new feature support, patches need to be >> incrementally applied and tested with temporal parameters. >> For such testing (or root-only) purposes, the new flag >> will

Re: [PATCH V2 06/15] taint: Add taint for insecure

On May 31, 2018 1:25:39 PM PDT, Andy Lutomirski wrote: >On Thu, May 31, 2018 at 10:58 AM Chang S. Bae > wrote: >> >> When adding new feature support, patches need to be >> incrementally applied and tested with temporal parameters. >> For such testing (or root-only) purposes, the new flag >> will

Re: [PATCH V2 02/15] x86/fsgsbase/64: Make ptrace read FS/GS base accurately

On May 31, 2018 1:14:59 PM PDT, Andy Lutomirski wrote: >On Thu, May 31, 2018 at 10:58 AM Chang S. Bae > wrote: >> >> From: Andy Lutomirski >> >> ptrace can read FS/GS base using the register access API >> (PTRACE_PEEKUSER, etc) or PTRACE_ARCH_PRCTL. Make both of these >> mechanisms return the

Re: [PATCH V2 02/15] x86/fsgsbase/64: Make ptrace read FS/GS base accurately

On May 31, 2018 1:14:59 PM PDT, Andy Lutomirski wrote: >On Thu, May 31, 2018 at 10:58 AM Chang S. Bae > wrote: >> >> From: Andy Lutomirski >> >> ptrace can read FS/GS base using the register access API >> (PTRACE_PEEKUSER, etc) or PTRACE_ARCH_PRCTL. Make both of these >> mechanisms return the

Re: [PATCH] x86, random: Fix get_random_bytes() warning in x86 start_kernel

On May 29, 2018 9:58:10 AM PDT, Prarit Bhargava wrote: > > >On 05/29/2018 12:07 PM, Theodore Y. Ts'o wrote: >> On Tue, May 29, 2018 at 11:01:07AM -0400, Prarit Bhargava wrote: >>> Kees, in early boot no pool is available so the stack canary is >initialized from >>> the TSC. Later in boot, the

Re: [PATCH] x86, random: Fix get_random_bytes() warning in x86 start_kernel

On May 29, 2018 9:58:10 AM PDT, Prarit Bhargava wrote: > > >On 05/29/2018 12:07 PM, Theodore Y. Ts'o wrote: >> On Tue, May 29, 2018 at 11:01:07AM -0400, Prarit Bhargava wrote: >>> Kees, in early boot no pool is available so the stack canary is >initialized from >>> the TSC. Later in boot, the

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 10:49:28 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 10:35 AM Tom Stellard >wrote: >> On 05/25/2018 10:31 AM, Nick Desaulniers wrote: >> > On Fri, May 25, 2018 at 9:53 AM wrote: >> >> On May 25, 2018

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 10:49:28 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 10:35 AM Tom Stellard >wrote: >> On 05/25/2018 10:31 AM, Nick Desaulniers wrote: >> > On Fri, May 25, 2018 at 9:53 AM wrote: >> >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers < >ndesaulni...@google.com> >> >

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 10:31:51 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 9:53 AM wrote: >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers > >wrote: >> >On Fri, May 25, 2018 at 9:33 AM wrote: >> >> On

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 10:31:51 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 9:53 AM wrote: >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers > >wrote: >> >On Fri, May 25, 2018 at 9:33 AM wrote: >> >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers >> > wrote: >> >When you say >> > >>

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 9:33 AM wrote: >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:43 PM wrote: >> >> On

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers wrote: >On Fri, May 25, 2018 at 9:33 AM wrote: >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:43 PM wrote: >> >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers >> > >> >wrote: >> >> >On Thu, May 24,

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:43 PM wrote: >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:43 PM wrote: >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin >wrote: >> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". >That >>

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:43 PM wrote: >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin

Re: [clang] stack protector and f1f029c7bf

On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:43 PM wrote: >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers > >wrote: >> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin >wrote: >> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". >That >>

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin wrote: >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". That >is >> unequivocally a compiler bug. > >Filed:

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin wrote: >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". That >is >> unequivocally a compiler bug. > >Filed: https://bugs.llvm.org/show_bug.cgi?id=37583 > >> >> You are

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 1:52:16 PM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers > >wrote: >> On Thu, May 24, 2018 at 11:59 AM wrote: >> > Issue 3: Let's face it, reading and writing the flags should be

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 1:52:16 PM PDT, Nick Desaulniers wrote: >On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers > >wrote: >> On Thu, May 24, 2018 at 11:59 AM wrote: >> > Issue 3: Let's face it, reading and writing the flags should be >builtins, >> exactly because it has to do stack operations, which

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 12:49:56 PM PDT, Tom Stellard wrote: >On 05/24/2018 11:19 AM, h...@zytor.com wrote: >> On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers > wrote: >>> H. Peter, >>> >>> It was reported [0] that compiling the Linux kernel with Clang + >>>

Re: [clang] stack protector and f1f029c7bf

On May 24, 2018 12:49:56 PM PDT, Tom Stellard wrote: >On 05/24/2018 11:19 AM, h...@zytor.com wrote: >> On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers > wrote: >>> H. Peter, >>> >>> It was reported [0] that compiling the Linux kernel with Clang + >>> CC_STACKPROTECTOR_STRONG was causing a crash

Re: [clang] stack protector and f1f029c7bf

On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers wrote: >H. Peter, > >It was reported [0] that compiling the Linux kernel with Clang + >CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due >to >how GCC does not emit a stack guard for static inline

Re: [clang] stack protector and f1f029c7bf

On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers wrote: >H. Peter, > >It was reported [0] that compiling the Linux kernel with Clang + >CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due >to >how GCC does not emit a stack guard for static inline functions (see >Alistair's

Re: [clang] stack protector and f1f029c7bf

On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers wrote: >H. Peter, > >It was reported [0] that compiling the Linux kernel with Clang + >CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due >to >how GCC does not emit a stack guard for static inline

Re: [clang] stack protector and f1f029c7bf

On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers wrote: >H. Peter, > >It was reported [0] that compiling the Linux kernel with Clang + >CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due >to >how GCC does not emit a stack guard for static inline functions (see >Alistair's

<    1   2   3   4   5   >