Re: [PATCH] objtool: Detect assembly code falling through to INT3 padding

On May 18, 2018 10:51:36 AM PDT, Alexey Dobriyan wrote: >On Fri, May 18, 2018 at 09:18:14AM +0200, Ingo Molnar wrote: >> The concept of built-in kernel tooling working at the machine code >level is just >> so powerful - we should have added our own KCC compiler 20 years ago.

Re: [PATCH] objtool: Detect assembly code falling through to INT3 padding

On May 18, 2018 10:51:36 AM PDT, Alexey Dobriyan wrote: >On Fri, May 18, 2018 at 09:18:14AM +0200, Ingo Molnar wrote: >> The concept of built-in kernel tooling working at the machine code >level is just >> so powerful - we should have added our own KCC compiler 20 years ago. > >...for two very

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:36:20 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 12:18 PM Nadav Amit >wrote: >>> Gnu ASM manual says: "Each

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:36:20 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 12:18 PM Nadav Amit >wrote: >>> Gnu ASM manual says: "Each time you run as it assembles exactly one >>> source program.

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:21:00 PM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > >> Gnu ASM manual says: "Each time you run as it assembles exactly one >source >> program. The source program is made up of one or more

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:21:00 PM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > >> Gnu ASM manual says: "Each time you run as it assembles exactly one >source >> program. The source program is made up of one or more files.” > >Ok, that counts as documentation,

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:02:50 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 11:34 AM wrote: >>> On May 18, 2018 11:25:32 AM PDT, Linus

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:02:50 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 11:34 AM wrote: >>> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >>> torva...@linux-foundation.org> wrote: >>>

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:50:12 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 11:34 AM wrote: > >> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >torva...@linux-foundation.org> wrote: > >> Unfortunately gcc doesn't guarantee that global

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:50:12 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 11:34 AM wrote: > >> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >torva...@linux-foundation.org> wrote: > >> Unfortunately gcc doesn't guarantee that global assembly inlines will >appear at the top of the

Re: [PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On May 18, 2018 11:00:05 AM PDT, Bart Van Assche wrote: >The next patch in this series introduces a call to cmpxchg64() >in the block layer core for those architectures on which this >functionality is available. Make it possible to test whether >cmpxchg64() is available by

Re: [PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On May 18, 2018 11:00:05 AM PDT, Bart Van Assche wrote: >The next patch in this series introduces a call to cmpxchg64() >in the block layer core for those architectures on which this >functionality is available. Make it possible to test whether >cmpxchg64() is available by introducing

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:25:32 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > >> Will it be ok just to use a global inline asm to set an “.include” >directive >> that gas would later process? (I can probably wrap it

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:25:32 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > >> Will it be ok just to use a global inline asm to set an “.include” >directive >> that gas would later process? (I can probably wrap it in a C macro so >it >> won’t be too disgusting)

Re: [PATCH 1/3] x86: verify_cpu: use 32-bit arithmetic

On May 17, 2018 2:30:01 PM PDT, Alexey Dobriyan wrote: >32-bit instructions are 1 byte shorter than 16-bit instructions. > >Signed-off-by: Alexey Dobriyan >--- > > arch/x86/kernel/verify_cpu.S |8 > 1 file changed, 4 insertions(+), 4

Re: [PATCH 1/3] x86: verify_cpu: use 32-bit arithmetic

On May 17, 2018 2:30:01 PM PDT, Alexey Dobriyan wrote: >32-bit instructions are 1 byte shorter than 16-bit instructions. > >Signed-off-by: Alexey Dobriyan >--- > > arch/x86/kernel/verify_cpu.S |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > >--- a/arch/x86/kernel/verify_cpu.S

Re: [PATCH] x86: pad assembly functions with INT3

On May 14, 2018 11:54:05 PM PDT, Ingo Molnar wrote: > >* h...@zytor.com wrote: > >> > I guess it won't try to speculatively execute the 'pad' >instructions - but you >> > can never really tell! >> > >> >David >> >> The CPU doesn't speculate down past an

Re: [PATCH] x86: pad assembly functions with INT3

On May 14, 2018 11:54:05 PM PDT, Ingo Molnar wrote: > >* h...@zytor.com wrote: > >> > I guess it won't try to speculatively execute the 'pad' >instructions - but you >> > can never really tell! >> > >> >David >> >> The CPU doesn't speculate down past an unconditional control >transfer.

RE: [PATCH] x86: pad assembly functions with INT3

On May 14, 2018 2:04:38 AM PDT, David Laight wrote: >From: H. Peter Anvin >> Sent: 11 May 2018 19:54 >> >> On 05/10/18 09:39, David Laight wrote: >> > From: Alexey Dobriyan >> >> Sent: 07 May 2018 22:38 >> >> >> >> Use INT3 instead of NOP. All that padding between

RE: [PATCH] x86: pad assembly functions with INT3

On May 14, 2018 2:04:38 AM PDT, David Laight wrote: >From: H. Peter Anvin >> Sent: 11 May 2018 19:54 >> >> On 05/10/18 09:39, David Laight wrote: >> > From: Alexey Dobriyan >> >> Sent: 07 May 2018 22:38 >> >> >> >> Use INT3 instead of NOP. All that padding between functions is >> >> an illegal

Re: [PATCH] x86: pad assembly functions with INT3

On May 7, 2018 2:37:55 PM PDT, Alexey Dobriyan wrote: >Use INT3 instead of NOP. All that padding between functions is >an illegal area, no legitimate code should jump into it. > >I've checked x86_64 allyesconfig disassembly, all changes looks sane: >INT3 is only used after

Re: [PATCH] x86: pad assembly functions with INT3

On May 7, 2018 2:37:55 PM PDT, Alexey Dobriyan wrote: >Use INT3 instead of NOP. All that padding between functions is >an illegal area, no legitimate code should jump into it. > >I've checked x86_64 allyesconfig disassembly, all changes looks sane: >INT3 is only used after RET or unconditional

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

On March 26, 2018 2:11:51 AM PDT, Thomas Gleixner wrote: >On Mon, 26 Mar 2018, Rajneesh Bhardwaj wrote: > >> On Sun, Mar 25, 2018 at 01:50:40PM +0200, Thomas Gleixner wrote: >> > On Thu, 22 Mar 2018, Anshuman Gupta wrote: >> > >> > > From: Rajneesh Bhardwaj

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

On March 26, 2018 2:11:51 AM PDT, Thomas Gleixner wrote: >On Mon, 26 Mar 2018, Rajneesh Bhardwaj wrote: > >> On Sun, Mar 25, 2018 at 01:50:40PM +0200, Thomas Gleixner wrote: >> > On Thu, 22 Mar 2018, Anshuman Gupta wrote: >> > >> > > From: Rajneesh Bhardwaj >> > > >> > > >From Skylake onwards,

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

On February 21, 2018 1:39:18 PM PST, Kees Cook wrote: >On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operations, adding bogus clobber >specifiers: >>

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

On February 21, 2018 1:39:18 PM PST, Kees Cook wrote: >On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operations, adding bogus clobber >specifiers: >> For one, on x86 there's no point

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended attributes (xattrs), for

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended attributes (xattrs), for

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 16, 2018 1:47:35 PM PST, Victor Kamensky wrote: > > >On Fri, 16 Feb 2018, Rob Landley wrote: > >> >> On 02/16/2018 02:59 PM, H. Peter Anvin wrote: >>> On 02/16/18 12:33, Taras Kondratiuk wrote: Many of the Linux security/integrity features are dependent on

Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description

On February 16, 2018 1:47:35 PM PST, Victor Kamensky wrote: > > >On Fri, 16 Feb 2018, Rob Landley wrote: > >> >> On 02/16/2018 02:59 PM, H. Peter Anvin wrote: >>> On 02/16/18 12:33, Taras Kondratiuk wrote: Many of the Linux security/integrity features are dependent on file metadata,

Re: [RFC 0/3] x86: Patchable constants

did it about 18 months ago. > >It was not really pursued all the way because it *is* a lot of extra >complexity, and I think there was some other hold-up, but he did have >skeleton code for the actual replacement. > >There was a thread on the x86 arch list with the subjec

Re: [RFC 0/3] x86: Patchable constants

because it *is* a lot of extra >complexity, and I think there was some other hold-up, but he did have >skeleton code for the actual replacement. > >There was a thread on the x86 arch list with the subject line > >Disgusting pseudo-self-modifying code idea: "variable

Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type

On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil" wrote: >On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote: >> Since non atomic readq() and writeq() were added some of the drivers >> would like to use it in a manner of: >> >>  #include >> ... >>  pr_debug("Debug

Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type

On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil" wrote: >On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote: >> Since non atomic readq() and writeq() were added some of the drivers >> would like to use it in a manner of: >> >>  #include >> ... >>  pr_debug("Debug value of some

Re: [RFC PATCH 00/16] PTI support for x86-32

On January 21, 2018 6:11:07 PM PST, Linus Torvalds wrote: >On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit >wrote: >> I wanted to see whether segments protection can be a replacement for >PTI >> (yes, excluding SMEP emulation), or whether

Re: [RFC PATCH 00/16] PTI support for x86-32

On January 21, 2018 6:11:07 PM PST, Linus Torvalds wrote: >On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit >wrote: >> I wanted to see whether segments protection can be a replacement for >PTI >> (yes, excluding SMEP emulation), or whether speculative execution >“ignores” >> limit checks, similarly

Re: [PATCH] x86-32: fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

On December 28, 2017 2:47:47 PM PST, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> From: Linus Torvalds >> Date: Wed, 27 Dec 2017 11:41:30 -0800 >> Subject: [PATCH] x86-32: fix kexec with stack canary

Re: [PATCH] x86-32: fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

On December 28, 2017 2:47:47 PM PST, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> From: Linus Torvalds >> Date: Wed, 27 Dec 2017 11:41:30 -0800 >> Subject: [PATCH] x86-32: fix kexec with stack canary >(CONFIG_CC_STACKPROTECTOR) >> >> Commit e802a51ede91 ("x86/idt: Consolidate IDT

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 6:54:55 PM PST, Linus Torvalds wrote: >On Tue, Dec 26, 2017 at 6:25 PM, wrote: >> >> This is why I personally prefer to see these kinds of terminal stubs >written in assembly explicitly: the C compiler simply doesn't have all

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 6:54:55 PM PST, Linus Torvalds wrote: >On Tue, Dec 26, 2017 at 6:25 PM, wrote: >> >> This is why I personally prefer to see these kinds of terminal stubs >written in assembly explicitly: the C compiler simply doesn't have all >the information needed to do the right thing.

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 6:16:37 PM PST, Linus Torvalds wrote: >On Tue, Dec 26, 2017 at 3:19 PM, Alexandru Chirvasitu > wrote: >> >> I went back to the initial problematic commit e802a51 and modified it >as you suggest: > >Thank you. > >> This did

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 6:16:37 PM PST, Linus Torvalds wrote: >On Tue, Dec 26, 2017 at 3:19 PM, Alexandru Chirvasitu > wrote: >> >> I went back to the initial problematic commit e802a51 and modified it >as you suggest: > >Thank you. > >> This did not work out for me, but now it fails differently.

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not back to normal, but at

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not back to normal, but at

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 3:19:00 PM PST, Alexandru Chirvasitu wrote: >On Tue, Dec 26, 2017 at 10:51:12AM -0800, Linus Torvalds wrote: >> [ Sorry, I was off-line on Christmas Eve due to festivities, and then >> yesterday because I've apparently caught a cold. >> >> Still not back to normal, but at

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 10:51:12 AM PST, Linus Torvalds wrote: >[ Sorry, I was off-line on Christmas Eve due to festivities, and then >yesterday because I've apparently caught a cold. > > Still not back to normal, but at least I can sit in front of the >computer

Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot

On December 26, 2017 10:51:12 AM PST, Linus Torvalds wrote: >[ Sorry, I was off-line on Christmas Eve due to festivities, and then >yesterday because I've apparently caught a cold. > > Still not back to normal, but at least I can sit in front of the >computer again ] > >On Mon, Dec 25, 2017 at

Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code

On November 29, 2017 12:58:15 PM PST, Andi Kleen wrote: >> We're really early in the boot -- startup_64 in decompression code -- >and >> I don't know a way print a message there. Is there a way? >> >> no_longmode handled by just hanging the machine. Is it enough for

Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code

On November 29, 2017 12:58:15 PM PST, Andi Kleen wrote: >> We're really early in the boot -- startup_64 in decompression code -- >and >> I don't know a way print a message there. Is there a way? >> >> no_longmode handled by just hanging the machine. Is it enough for >no_la57 >> case too? > >The

Re: x86: CR4 update when IRQs are enabled

On November 15, 2017 3:31:50 PM PST, Nadav Amit wrote: >Ping? > >Nadav Amit wrote: > >> CC’ing more people, and adding a patch to clarify... >> >> Nadav Amit wrote: >> >>> I am puzzled by the comment in tlb_state.cr4 , which

Re: x86: CR4 update when IRQs are enabled

On November 15, 2017 3:31:50 PM PST, Nadav Amit wrote: >Ping? > >Nadav Amit wrote: > >> CC’ing more people, and adding a patch to clarify... >> >> Nadav Amit wrote: >> >>> I am puzzled by the comment in tlb_state.cr4 , which says: >>> >>> /* >>>* Access to this CR4 shadow and

Re: [PATCH 0/6] Boot-time switching between 4- and 5-level paging for 4.15, Part 1

On October 17, 2017 5:42:41 PM GMT+02:00, "Kirill A. Shutemov" wrote: >On Tue, Oct 03, 2017 at 11:27:54AM +0300, Kirill A. Shutemov wrote: >> On Fri, Sep 29, 2017 at 05:08:15PM +0300, Kirill A. Shutemov wrote: >> > The first bunch of patches that prepare kernel to boot-time

Re: [PATCH 0/6] Boot-time switching between 4- and 5-level paging for 4.15, Part 1

On October 17, 2017 5:42:41 PM GMT+02:00, "Kirill A. Shutemov" wrote: >On Tue, Oct 03, 2017 at 11:27:54AM +0300, Kirill A. Shutemov wrote: >> On Fri, Sep 29, 2017 at 05:08:15PM +0300, Kirill A. Shutemov wrote: >> > The first bunch of patches that prepare kernel to boot-time >switching >> >

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On October 10, 2017 2:22:42 PM PDT, Nick Terrell wrote: >Hi, > >This patch set adds support for a ZSTD-compressed kernel and ramdisk >images in the kernel boot process. It only integrates the support with >x86, though the first patch is generic to all architectures. > >Zstandard

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On October 10, 2017 2:22:42 PM PDT, Nick Terrell wrote: >Hi, > >This patch set adds support for a ZSTD-compressed kernel and ramdisk >images in the kernel boot process. It only integrates the support with >x86, though the first patch is generic to all architectures. > >Zstandard requires slightly

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> >> > diff --git a/arch/x86/entry/entry_64.S >b/arch/x86/entry/entry_64.S >> >> > index 4916725..3bab6af 100644 >> >> > --- a/arch/x86/entry/entry_64.S >> >> > +++

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> >> > diff --git a/arch/x86/entry/entry_64.S >b/arch/x86/entry/entry_64.S >> >> > index 4916725..3bab6af 100644 >> >> > --- a/arch/x86/entry/entry_64.S >> >> > +++ b/arch/x86/entry/entry_64.S >> >> > @@

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> >> > diff --git a/arch/x86/entry/entry_64.S >b/arch/x86/entry/entry_64.S >> >> > index 4916725..3bab6af 100644 >> >> > --- a/arch/x86/entry/entry_64.S >> >> > +++

Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y

On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> >> > diff --git a/arch/x86/entry/entry_64.S >b/arch/x86/entry/entry_64.S >> >> > index 4916725..3bab6af 100644 >> >> > --- a/arch/x86/entry/entry_64.S >> >> > +++ b/arch/x86/entry/entry_64.S >> >> > @@

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

g the >security >> >version >> >> >> or the attacker may alter the security version stealthily. >> >> >> >> >> > Any comment? >> >> > >> >> >> >> This is now entirely x86-specific. My preference would be to h

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

should show >to >> >prevent >> >> >> the user from loading a vulnerable kernel accidentally. >> >> >> >> >> >> Enabling UEFI Secure Boot is recommended when using the >security >> >version >> >> >> or the

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

ing UEFI Secure Boot is recommended when using the security >version >> >> or the attacker may alter the security version stealthily. >> >> >> > Any comment? >> > >> >> This is now entirely x86-specific. My preference would be to have a >&g

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

using the security >version >> >> or the attacker may alter the security version stealthily. >> >> >> > Any comment? >> > >> >> This is now entirely x86-specific. My preference would be to have a >> generic solution instead. >>

Re: [tip:x86/asm] objtool: Track DRAP separately from callee-saved registers

On August 11, 2017 9:57:13 AM PDT, Josh Poimboeuf wrote: >On Fri, Aug 11, 2017 at 09:22:11AM -0700, Andy Lutomirski wrote: >> On Fri, Aug 11, 2017 at 5:13 AM, tip-bot for Josh Poimboeuf >> wrote: >> > Commit-ID: bf4d1a83758368c842c94cab9661a75ca98bc848 >>

Re: [tip:x86/asm] objtool: Track DRAP separately from callee-saved registers

On August 11, 2017 9:57:13 AM PDT, Josh Poimboeuf wrote: >On Fri, Aug 11, 2017 at 09:22:11AM -0700, Andy Lutomirski wrote: >> On Fri, Aug 11, 2017 at 5:13 AM, tip-bot for Josh Poimboeuf >> wrote: >> > Commit-ID: bf4d1a83758368c842c94cab9661a75ca98bc848 >> > Gitweb:

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >On 2017/6/29 5:43, h...@zytor.com wrote: >> On June 27, 2017 9:35:10 PM PDT, zhong jiang >wrote: >>> Hi, Ingo >>> >>> Thank you for the comment. >>> On 2017/6/22 0:40, Ingo Molnar wrote: *

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >On 2017/6/29 5:43, h...@zytor.com wrote: >> On June 27, 2017 9:35:10 PM PDT, zhong jiang >wrote: >>> Hi, Ingo >>> >>> Thank you for the comment. >>> On 2017/6/22 0:40, Ingo Molnar wrote: * zhong jiang wrote: > when shift

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On June 27, 2017 9:35:10 PM PDT, zhong jiang wrote: >Hi, Ingo > >Thank you for the comment. >On 2017/6/22 0:40, Ingo Molnar wrote: >> * zhong jiang wrote: >> >>> when shift expoment is negative, left shift alway zero. therefore, >we >>> modify the

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On June 27, 2017 9:35:10 PM PDT, zhong jiang wrote: >Hi, Ingo > >Thank you for the comment. >On 2017/6/22 0:40, Ingo Molnar wrote: >> * zhong jiang wrote: >> >>> when shift expoment is negative, left shift alway zero. therefore, >we >>> modify the logic to avoid the warining. >>> >>>

Re: [PATCH v4 3/3] x86/build: Specify stack alignment for clang

On June 19, 2017 11:37:57 AM PDT, Matthias Kaehlcke wrote: >For gcc stack alignment is configured with >-mpreferred-stack-boundary=N, >clang has the option -mstack-alignment=N for that purpose. Use the same >alignment as with gcc. > >If the alignment is not specified clang

Re: [PATCH v4 3/3] x86/build: Specify stack alignment for clang

On June 19, 2017 11:37:57 AM PDT, Matthias Kaehlcke wrote: >For gcc stack alignment is configured with >-mpreferred-stack-boundary=N, >clang has the option -mstack-alignment=N for that purpose. Use the same >alignment as with gcc. > >If the alignment is not specified clang assumes an alignment of

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On May 28, 2017 2:29:32 AM PDT, Dmitry Vyukov wrote: >On Sun, May 28, 2017 at 1:02 AM, wrote: >> On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov >wrote: >>>Some 64-bit atomic operations use 'long long' as operand/return type >>>(e.g.

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On May 28, 2017 2:29:32 AM PDT, Dmitry Vyukov wrote: >On Sun, May 28, 2017 at 1:02 AM, wrote: >> On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov >wrote: >>>Some 64-bit atomic operations use 'long long' as operand/return type >>>(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov wrote: >Some 64-bit atomic operations use 'long long' as operand/return type >(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h); >while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h). >This makes it

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov wrote: >Some 64-bit atomic operations use 'long long' as operand/return type >(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h); >while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h). >This makes it impossible to write

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov" wrote: >On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote: >> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov >> wrote: >> > Here' my first attempt to bring boot-time

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov" wrote: >On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote: >> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov >> wrote: >> > Here' my first attempt to bring boot-time between 4- and 5-level >paging. >> > It looks not too

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 12:23:18 PM PDT, Dave Hansen wrote: >On 05/26/2017 11:24 AM, h...@zytor.com wrote: >> The only case where that even has any utility is for an application >> to want more than 128 TiB address space on a machine with no more >> than 64 TiB of RAM. It is kind

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 12:23:18 PM PDT, Dave Hansen wrote: >On 05/26/2017 11:24 AM, h...@zytor.com wrote: >> The only case where that even has any utility is for an application >> to want more than 128 TiB address space on a machine with no more >> than 64 TiB of RAM. It is kind of a narrow use case, I

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 8:51:48 AM PDT, Linus Torvalds wrote: >On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov > wrote: >> >> I don't see how kernel threads can use 4-level paging. It doesn't >work >> from virtual memory layout POV. Kernel claims

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On May 26, 2017 8:51:48 AM PDT, Linus Torvalds wrote: >On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov > wrote: >> >> I don't see how kernel threads can use 4-level paging. It doesn't >work >> from virtual memory layout POV. Kernel claims half of full virtual >address >> space for itself --

Re: [PATCH 7/7] DWARF: add the config option

On May 22, 2017 10:49:06 PM PDT, Ingo Molnar wrote: > >* H. Peter Anvin wrote: > >> On 05/22/17 04:12, Ingo Molnar wrote: >> \>> >> >> This construct might be useful for other arches, which is why I >called >> >> it "FP" instead of "BP". But then I ruined that

Re: [PATCH 7/7] DWARF: add the config option

On May 22, 2017 10:49:06 PM PDT, Ingo Molnar wrote: > >* H. Peter Anvin wrote: > >> On 05/22/17 04:12, Ingo Molnar wrote: >> \>> >> >> This construct might be useful for other arches, which is why I >called >> >> it "FP" instead of "BP". But then I ruined that with the last 3 >:-) >> > >> >

Re: [PATCH 7/7] DWARF: add the config option

On May 8, 2017 8:38:31 PM PDT, Josh Poimboeuf wrote: >On Mon, May 08, 2017 at 07:31:50PM -0700, Andy Lutomirski wrote: >> On Mon, May 8, 2017 at 6:38 PM, Josh Poimboeuf >wrote: >> >> Also, don't you need some indication of which reg is the base from >>

Re: [PATCH 7/7] DWARF: add the config option

On May 8, 2017 8:38:31 PM PDT, Josh Poimboeuf wrote: >On Mon, May 08, 2017 at 07:31:50PM -0700, Andy Lutomirski wrote: >> On Mon, May 8, 2017 at 6:38 PM, Josh Poimboeuf >wrote: >> >> Also, don't you need some indication of which reg is the base from >> >> which you find previous frame? After

Re: [PATCH 7/7] DWARF: add the config option

On May 8, 2017 7:40:49 AM PDT, Josh Poimboeuf wrote: >On Sun, May 07, 2017 at 10:35:28PM -0700, Andy Lutomirski wrote: >> I think that, if the code were sufficiently robust, it would be handy >> if the unwinder displayed function arguments. DWARF can do that to a >> limited

Re: [PATCH 7/7] DWARF: add the config option

On May 8, 2017 7:40:49 AM PDT, Josh Poimboeuf wrote: >On Sun, May 07, 2017 at 10:35:28PM -0700, Andy Lutomirski wrote: >> I think that, if the code were sufficiently robust, it would be handy >> if the unwinder displayed function arguments. DWARF can do that to a >> limited extent. > >Honestly I

Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

On May 6, 2017 1:16:35 AM PDT, Peter Zijlstra wrote: >On Fri, May 05, 2017 at 01:36:34PM -0700, Michael Davidson wrote: > >> There are a few lingering places in the kernel which use variable >> length arrays in structs (eg the raid10 driver) which don't build >with >> clang

Re: [PATCH 7/7] DWARF: add the config option

On May 7, 2017 10:59:16 AM PDT, Ingo Molnar wrote: > >* Josh Poimboeuf wrote: > >> One instance of the structure would exist for each time the stack >> pointer changes, e.g. for every function entry, push/pop, and rsp >> add/subtract. The data could be

Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

On May 6, 2017 1:16:35 AM PDT, Peter Zijlstra wrote: >On Fri, May 05, 2017 at 01:36:34PM -0700, Michael Davidson wrote: > >> There are a few lingering places in the kernel which use variable >> length arrays in structs (eg the raid10 driver) which don't build >with >> clang and that is about it.

Re: [PATCH 7/7] DWARF: add the config option

On May 7, 2017 10:59:16 AM PDT, Ingo Molnar wrote: > >* Josh Poimboeuf wrote: > >> One instance of the structure would exist for each time the stack >> pointer changes, e.g. for every function entry, push/pop, and rsp >> add/subtract. The data could be assembled and sorted offline, >possibly >>

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On May 6, 2017 10:34:49 AM PDT, Brian Gerst wrote: >On Fri, May 5, 2017 at 5:26 AM, Gary Lin wrote: >> This is a different approach to replace my previous implementation of >> Security Version(*). Instead of using the fields in the PE/COFF >header, >> this

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On May 6, 2017 10:34:49 AM PDT, Brian Gerst wrote: >On Fri, May 5, 2017 at 5:26 AM, Gary Lin wrote: >> This is a different approach to replace my previous implementation of >> Security Version(*). Instead of using the fields in the PE/COFF >header, >> this commit adds secdata_offset in the setup

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On May 5, 2017 2:26:39 AM PDT, Gary Lin wrote: >This is a different approach to replace my previous implementation of >Security Version(*). Instead of using the fields in the PE/COFF header, >this commit adds secdata_offset in the setup header for the file offset >of secdata.

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On May 5, 2017 2:26:39 AM PDT, Gary Lin wrote: >This is a different approach to replace my previous implementation of >Security Version(*). Instead of using the fields in the PE/COFF header, >this commit adds secdata_offset in the setup header for the file offset >of secdata. Currently, the

<    1   2   3   4   5   >