Re: Compat 32-bit syscall entry from 64-bit task!?

On Wed, Mar 8, 2017 at 3:41 PM, Dmitry V. Levin wrote: > Hi, > > On Thu, Jan 26, 2012 at 07:03:43PM +0100, Denys Vlasenko wrote: >> Hi Linus, >> >> On Thu, Jan 26, 2012 at 4:47 AM, Linus Torvalds >> wrote: >> >> Please look at strace source,

Re: Compat 32-bit syscall entry from 64-bit task!?

On Wed, Mar 8, 2017 at 3:41 PM, Dmitry V. Levin wrote: > Hi, > > On Thu, Jan 26, 2012 at 07:03:43PM +0100, Denys Vlasenko wrote: >> Hi Linus, >> >> On Thu, Jan 26, 2012 at 4:47 AM, Linus Torvalds >> wrote: >> >> Please look at strace source, get_scno() function, where >> >> it reads syscall no

Re: [RFC] capabilities: Ambient capabilities

On Thu, Mar 12, 2015 at 3:10 PM, Andrew G. Morgan wrote: > I'm unclear why you refer to the inheritable set in this test: > > + } else { > + if (arg2 == PR_CAP_AMBIENT_RAISE && > + (!cap_raised(current_cred()->cap_permitted, arg3) >

Re: [RFC] capabilities: Ambient capabilities

On Thu, Mar 12, 2015 at 3:10 PM, Andrew G. Morgan mor...@kernel.org wrote: I'm unclear why you refer to the inheritable set in this test: + } else { + if (arg2 == PR_CAP_AMBIENT_RAISE + (!cap_raised(current_cred()-cap_permitted,

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Jan 15, 2015 8:43 AM, "Kirill A. Shutemov" wrote: > > On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote: > > On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart wrote: > > > On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote: > >

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Jan 15, 2015 8:43 AM, Kirill A. Shutemov kir...@shutemov.name wrote: On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote: On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart dvh...@infradead.org wrote: On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote: On Mon

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart wrote: > On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> &g

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart dvh...@infradead.org wrote: On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: &g

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: &g

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:26 PM, Borislav Petkov wrote: > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: >> What aspect of the old behavior is better than the new default behavior? > > Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0 >

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov wrote: > On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: >> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart wrote: >> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: >> >>

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart wrote: > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: >> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: >> > thinkpad-acpi using software mute simplifies the driver and the user >> > experience >> > significantly.

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart dvh...@infradead.org wrote: On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:26 PM, Borislav Petkov b...@alien8.de wrote: On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: What aspect of the old behavior is better than the new default behavior? Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0 thing

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart dvh...@infradead.org wrote: On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov wrote: On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: thinkpad-acpi using software mute simplifies the driver and the user experience

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Sun, Jan 11, 2015 at 2:58 PM, Kirill A. Shutemov wrote: > On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: >> thinkpad-acpi using software mute simplifies the driver and the user >> experience >> significantly. > > Except when it doesn't. > > I'm probably in minority, but I don't

Re: [GIT PULL] platform-drivers-x86 for 3.19

On Sun, Jan 11, 2015 at 2:58 PM, Kirill A. Shutemov kir...@shutemov.name wrote: On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote: thinkpad-acpi using software mute simplifies the driver and the user experience significantly. Except when it doesn't. I'm probably in minority, but

Re: DO NOT APPLY: x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

On Tue, Jul 15, 2014 at 4:52 PM, Greg KH wrote: > On Tue, Jul 15, 2014 at 04:21:46PM -0700, Andrew Lutomirski wrote: >> On Tue, Jul 15, 2014 at 2:28 PM, Kamal Mostafa wrote: >> > 3.13.11.5 -stable review patch. If anyone has any objections, please

DO NOT APPLY: x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

On Tue, Jul 15, 2014 at 2:28 PM, Kamal Mostafa wrote: > 3.13.11.5 -stable review patch. If anyone has any objections, please let me > know. > > -- > > From: "H. Peter Anvin" > > commit 3891a04aafd668686239349ea58f3314ea2af86b upstream. Do not apply to any -stable release yet.

DO NOT APPLY: x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

On Tue, Jul 15, 2014 at 2:28 PM, Kamal Mostafa ka...@canonical.com wrote: 3.13.11.5 -stable review patch. If anyone has any objections, please let me know. -- From: H. Peter Anvin h...@linux.intel.com commit 3891a04aafd668686239349ea58f3314ea2af86b upstream. Do not apply

Re: DO NOT APPLY: x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

On Tue, Jul 15, 2014 at 4:52 PM, Greg KH g...@kroah.com wrote: On Tue, Jul 15, 2014 at 04:21:46PM -0700, Andrew Lutomirski wrote: On Tue, Jul 15, 2014 at 2:28 PM, Kamal Mostafa ka...@canonical.com wrote: 3.13.11.5 -stable review patch. If anyone has any objections, please let me know

Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference

On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering wrote: > On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: > >> > Hmm? You should "exec" the real daemon binary at the end, not just fork >> > it off. That wait the shell script process is replaced by the daemon >> > binary,

Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference

On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering mzxre...@0pointer.de wrote: On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: Hmm? You should exec the real daemon binary at the end, not just fork it off. That wait the shell script process is replaced by the daemon

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 28, 2014 at 5:02 PM, Andrew Lutomirski wrote: > On Mon, Apr 28, 2014 at 4:08 PM, H. Peter Anvin wrote: >> On 04/28/2014 04:05 PM, H. Peter Anvin wrote: >>> >>> So I tried writing this bit up, but it fails in some rather spectacular >>> ways. Furt

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 28, 2014 at 4:08 PM, H. Peter Anvin wrote: > On 04/28/2014 04:05 PM, H. Peter Anvin wrote: >> >> So I tried writing this bit up, but it fails in some rather spectacular >> ways. Furthermore, I have been unable to debug it under Qemu, because >> breakpoints don't work right (common

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 28, 2014 at 4:08 PM, H. Peter Anvin h...@linux.intel.com wrote: On 04/28/2014 04:05 PM, H. Peter Anvin wrote: So I tried writing this bit up, but it fails in some rather spectacular ways. Furthermore, I have been unable to debug it under Qemu, because breakpoints don't work right

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 28, 2014 at 5:02 PM, Andrew Lutomirski aml...@gmail.com wrote: On Mon, Apr 28, 2014 at 4:08 PM, H. Peter Anvin h...@linux.intel.com wrote: On 04/28/2014 04:05 PM, H. Peter Anvin wrote: So I tried writing this bit up, but it fails in some rather spectacular ways. Furthermore, I

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Thu, Apr 24, 2014 at 3:37 PM, H. Peter Anvin wrote: > On 04/24/2014 03:31 PM, Andrew Lutomirski wrote: >> >> I was imagining just randomizing a couple of high bits so the whole >> espfix area moves as a unit. >> >>> We could XOR with a random constant with

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Thu, Apr 24, 2014 at 3:24 PM, H. Peter Anvin wrote: > On 04/23/2014 09:53 PM, Andrew Lutomirski wrote: >>> >>> - The user can put arbitrary data in registers before returning to the >>> LDT in order to get it saved at a known address accessible from the &g

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Thu, Apr 24, 2014 at 3:24 PM, H. Peter Anvin h...@linux.intel.com wrote: On 04/23/2014 09:53 PM, Andrew Lutomirski wrote: - The user can put arbitrary data in registers before returning to the LDT in order to get it saved at a known address accessible from the kernel. With SMAP and KASLR

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Thu, Apr 24, 2014 at 3:37 PM, H. Peter Anvin h...@zytor.com wrote: On 04/24/2014 03:31 PM, Andrew Lutomirski wrote: I was imagining just randomizing a couple of high bits so the whole espfix area moves as a unit. We could XOR with a random constant with no penalty at all. Only problem

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 9:13 PM, comex wrote: > On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin wrote: >> This is a prototype of espfix for the 64-bit kernel. espfix is a >> workaround for the architectural definition of IRET, which fails to >> restore bits [31:16] of %esp when returning to a

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 10:28 AM, H. Peter Anvin wrote: > On 04/23/2014 10:25 AM, Andrew Lutomirski wrote: >> On Wed, Apr 23, 2014 at 10:16 AM, H. Peter Anvin wrote: >>> On 04/23/2014 10:08 AM, Andrew Lutomirski wrote: >>>> >>>> The only way I can

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 10:16 AM, H. Peter Anvin wrote: > On 04/23/2014 10:08 AM, Andrew Lutomirski wrote: >> >> The only way I can see to trigger the race is with sigreturn, but it's >> still there. Sigh. >> > > I don't see why sigreturn needs to be involve

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 8:53 AM, H. Peter Anvin wrote: > On 04/23/2014 02:54 AM, One Thousand Gnomes wrote: >>> Ideally the tests should be doable such that on a normal machine the >>> tests can be overlapped with the other things we have to do on that >>> path. The exit branch will be strongly

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 8:53 AM, H. Peter Anvin h...@zytor.com wrote: On 04/23/2014 02:54 AM, One Thousand Gnomes wrote: Ideally the tests should be doable such that on a normal machine the tests can be overlapped with the other things we have to do on that path. The exit branch will be

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 10:16 AM, H. Peter Anvin h...@zytor.com wrote: On 04/23/2014 10:08 AM, Andrew Lutomirski wrote: The only way I can see to trigger the race is with sigreturn, but it's still there. Sigh. I don't see why sigreturn needs to be involved... all you need is modify_ldt

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 10:28 AM, H. Peter Anvin h...@zytor.com wrote: On 04/23/2014 10:25 AM, Andrew Lutomirski wrote: On Wed, Apr 23, 2014 at 10:16 AM, H. Peter Anvin h...@zytor.com wrote: On 04/23/2014 10:08 AM, Andrew Lutomirski wrote: The only way I can see to trigger the race

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Wed, Apr 23, 2014 at 9:13 PM, comex com...@gmail.com wrote: On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin h...@linux.intel.com wrote: This is a prototype of espfix for the 64-bit kernel. espfix is a workaround for the architectural definition of IRET, which fails to restore bits [31:16]

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 6:17 PM, H. Peter Anvin wrote: > Another spin of the prototype. This one avoids the espfix for anything > but #GP, and avoids save/restore/saving registers... one can wonder, > though, how much that actually matters in practice. > > It still does redundant SWAPGS on the

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:29 AM, H. Peter Anvin wrote: > On 04/22/2014 10:19 AM, Linus Torvalds wrote: >> On Tue, Apr 22, 2014 at 10:11 AM, Andrew Lutomirski wrote: >>> >>>> >>>> Anyway, if done correctly, this whole espfix should be totally free >&

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:26 AM, Borislav Petkov wrote: > On Tue, Apr 22, 2014 at 10:11:27AM -0700, H. Peter Anvin wrote: >> The fastpath interference is: >> >> 1. Testing for an LDT SS selector before IRET. This is actually easier >> than on 32 bits, because on 64 bits the SS:RSP on the stack

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:09 AM, H. Peter Anvin wrote: > > As for Andy's questions: > >> What happens on the IST entries? If I've read your patch right, >> you're still switching back to the normal stack, which looks >> questionable. > > No, in that case %rsp won't point into the espfix region,

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:04 AM, Linus Torvalds wrote: > On Tue, Apr 22, 2014 at 10:00 AM, Andrew Lutomirski wrote: >> >> My point is that it may be safe to remove the special espfix fixup >> from #PF, which is probably the most performance-critical piece here, >

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 9:43 AM, Linus Torvalds wrote: > On Tue, Apr 22, 2014 at 9:33 AM, Andrew Lutomirski wrote: >> >> For the espfix_adjust_stack thing, when can it actually need to do >> anything? irqs should be off, I think, and MCE, NMI, and debug >> excepti

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 9:10 AM, H. Peter Anvin wrote: > Honestly, guys... you're painting the bikeshed at the moment. > > Initialization is the easiest bit of all this code. The tricky part is > *the rest of the code*, i.e. the stuff in entry_64.S. That's because the initialization code is

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 7:46 AM, Borislav Petkov wrote: > On Tue, Apr 22, 2014 at 01:23:12PM +0200, Borislav Petkov wrote: >> I wonder if it would be workable to use a bit in the espfix PGD to >> denote that it has been initialized already... I hear, near NX there's >> some room :-) > > Ok, I

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 7:46 AM, Borislav Petkov b...@alien8.de wrote: On Tue, Apr 22, 2014 at 01:23:12PM +0200, Borislav Petkov wrote: I wonder if it would be workable to use a bit in the espfix PGD to denote that it has been initialized already... I hear, near NX there's some room :-) Ok,

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 9:10 AM, H. Peter Anvin h...@zytor.com wrote: Honestly, guys... you're painting the bikeshed at the moment. Initialization is the easiest bit of all this code. The tricky part is *the rest of the code*, i.e. the stuff in entry_64.S. That's because the initialization

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 9:43 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Apr 22, 2014 at 9:33 AM, Andrew Lutomirski aml...@gmail.com wrote: For the espfix_adjust_stack thing, when can it actually need to do anything? irqs should be off, I think, and MCE, NMI, and debug

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:04 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Apr 22, 2014 at 10:00 AM, Andrew Lutomirski aml...@gmail.com wrote: My point is that it may be safe to remove the special espfix fixup from #PF, which is probably the most performance-critical piece

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:09 AM, H. Peter Anvin h...@zytor.com wrote: As for Andy's questions: What happens on the IST entries? If I've read your patch right, you're still switching back to the normal stack, which looks questionable. No, in that case %rsp won't point into the espfix

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:26 AM, Borislav Petkov b...@alien8.de wrote: On Tue, Apr 22, 2014 at 10:11:27AM -0700, H. Peter Anvin wrote: The fastpath interference is: 1. Testing for an LDT SS selector before IRET. This is actually easier than on 32 bits, because on 64 bits the SS:RSP on the

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 10:29 AM, H. Peter Anvin h...@zytor.com wrote: On 04/22/2014 10:19 AM, Linus Torvalds wrote: On Tue, Apr 22, 2014 at 10:11 AM, Andrew Lutomirski aml...@gmail.com wrote: Anyway, if done correctly, this whole espfix should be totally free for normal processes, since

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Tue, Apr 22, 2014 at 6:17 PM, H. Peter Anvin h...@linux.intel.com wrote: Another spin of the prototype. This one avoids the espfix for anything but #GP, and avoids save/restore/saving registers... one can wonder, though, how much that actually matters in practice. It still does redundant

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin wrote: > Race condition (although with x86 being globally ordered, it probably can't > actually happen.) The bitmask is probably the way to go. Does the race matter? In the worst case you take the lock unnecessarily. But yes, the bitmask is

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 6:14 PM, H. Peter Anvin wrote: > I wanted to avoid the "another cpu made this allocation, now I have to free" > crap, but I also didn't want to grab the lock if there was no work needed. I guess you also want to avoid bouncing all these cachelines around on boot on bit

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 5:53 PM, H. Peter Anvin wrote: > Well, if 2^17 CPUs are allocated we might 2K pages allocated. We could > easily do a bitmap here, of course. NR_CPUS/64 is a small number, and would > reduce the code complexity. > Even simpler: just get rid of the check entirely.

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 4:29 PM, H. Peter Anvin wrote: > On 04/21/2014 04:19 PM, Andrew Lutomirski wrote: >> >> Hahaha! :) >> >> Some comments: >> >> Does returning to 64-bit CS with 16-bit SS not need espfix? > > There is no such thing. With a 64-bi

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 3:47 PM, H. Peter Anvin wrote: > This is a prototype of espfix for the 64-bit kernel. espfix is a > workaround for the architectural definition of IRET, which fails to > restore bits [31:16] of %esp when returning to a 16-bit stack > segment. We have a workaround for the

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 3:47 PM, H. Peter Anvin h...@linux.intel.com wrote: This is a prototype of espfix for the 64-bit kernel. espfix is a workaround for the architectural definition of IRET, which fails to restore bits [31:16] of %esp when returning to a 16-bit stack segment. We have a

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 4:29 PM, H. Peter Anvin h...@zytor.com wrote: On 04/21/2014 04:19 PM, Andrew Lutomirski wrote: Hahaha! :) Some comments: Does returning to 64-bit CS with 16-bit SS not need espfix? There is no such thing. With a 64-bit CS, the flags on SS are ignored (although

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 5:53 PM, H. Peter Anvin h...@zytor.com wrote: Well, if 2^17 CPUs are allocated we might 2K pages allocated. We could easily do a bitmap here, of course. NR_CPUS/64 is a small number, and would reduce the code complexity. Even simpler: just get rid of the check

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 6:14 PM, H. Peter Anvin h...@zytor.com wrote: I wanted to avoid the another cpu made this allocation, now I have to free crap, but I also didn't want to grab the lock if there was no work needed. I guess you also want to avoid bouncing all these cachelines around on

Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin h...@zytor.com wrote: Race condition (although with x86 being globally ordered, it probably can't actually happen.) The bitmask is probably the way to go. Does the race matter? In the worst case you take the lock unnecessarily. But yes, the

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

On Sun, Aug 4, 2013 at 8:45 PM, Linus Torvalds wrote: > The patch looks right to me - we should pass in similar flags for the > create case as for tmpfile to the filesystem. Alternatively, in case anyone ever wants to add more O_TMPFILE-related flags, open could return -EINVAL if __O_TMPFILE is

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

On Sun, Aug 4, 2013 at 8:45 PM, Linus Torvalds torva...@linux-foundation.org wrote: The patch looks right to me - we should pass in similar flags for the create case as for tmpfile to the filesystem. Alternatively, in case anyone ever wants to add more O_TMPFILE-related flags, open could return

Re: adopt(pid_t pid) syscall proposal [patch included]

On Tue, Jun 11, 2013 at 11:38 AM, wrote: > On Tue, Jun 11, 2013 at 09:48:22AM -0700, Andy Lutomirski wrote: >> On 06/10/2013 06:23 PM, vcap...@gnugeneration.com wrote: >> >+if (!uid_eq(cred->euid, tcred->suid) && >> >+!uid_eq(cred->euid, tcred->uid)

Re: adopt(pid_t pid) syscall proposal [patch included]

On Tue, Jun 11, 2013 at 11:38 AM, vcap...@gnugeneration.com wrote: On Tue, Jun 11, 2013 at 09:48:22AM -0700, Andy Lutomirski wrote: On 06/10/2013 06:23 PM, vcap...@gnugeneration.com wrote: +if (!uid_eq(cred-euid, tcred-suid) +!uid_eq(cred-euid,

Re: [PATCH 54/74] x86, lto, vdso: Don't duplicate vvar address variables

On Sat, Aug 18, 2012 at 7:56 PM, Andi Kleen wrote: > From: Andi Kleen > > Every includer of vvar.h currently gets own static variables > for all the vvar addresses. Generate just one set each for the > main kernel and for the vdso. This saves some data space. > > Cc: Andy Lutomirski >

Re: [PATCH 54/74] x86, lto, vdso: Don't duplicate vvar address variables

On Sat, Aug 18, 2012 at 7:56 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com Every includer of vvar.h currently gets own static variables for all the vvar addresses. Generate just one set each for the main kernel and for the vdso. This saves some data space.

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

On Fri, Aug 10, 2012 at 2:14 AM, James Morris wrote: > On Sat, 14 Jul 2012, Will Drewry wrote: > >> Agreed :) I don't mind making tweaks to get it right, but this only >> matters to users that want to: >> - use seccomp filter >> - with ptrace (or trap with resumption and not sigreturn) >> - of

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

On Fri, Aug 10, 2012 at 2:14 AM, James Morris jmor...@namei.org wrote: On Sat, 14 Jul 2012, Will Drewry wrote: Agreed :) I don't mind making tweaks to get it right, but this only matters to users that want to: - use seccomp filter - with ptrace (or trap with resumption and not sigreturn) -

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry wrote: > On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry wrote: >> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski wrote: >>> I think I'd prefer if changing to something other than whatever value is >>> used to

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry w...@chromium.org wrote: On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry w...@chromium.org wrote: On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski l...@mit.edu wrote: I think I'd prefer if changing to something other than whatever value is used

Re: [PATCH v2] x86/vsyscall: allow seccomp filter in vsyscall=emulate

On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry wrote: > If a seccomp filter program is installed, older static binaries and > distributions with older libc implementations (glibc 2.13 and earlier) > that rely on vsyscall use will be terminated regardless of the filter > program policy when

Re: [PATCH] x86/vsyscall: allow seccomp filter in vsyscall=emulate

On Thu, Jul 12, 2012 at 10:17 PM, Will Drewry wrote: > If a seccomp filter program is installed, older static binaries and > distributions with older libc implementations (glibc 2.13 and earlier) > that rely on vsyscall use will be terminated regardless of the filter > program policy when

Re: [PATCH] x86/vsyscall: allow seccomp filter in vsyscall=emulate

On Thu, Jul 12, 2012 at 10:17 PM, Will Drewry w...@chromium.org wrote: If a seccomp filter program is installed, older static binaries and distributions with older libc implementations (glibc 2.13 and earlier) that rely on vsyscall use will be terminated regardless of the filter program policy

Re: [PATCH v2] x86/vsyscall: allow seccomp filter in vsyscall=emulate

On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry w...@chromium.org wrote: If a seccomp filter program is installed, older static binaries and distributions with older libc implementations (glibc 2.13 and earlier) that rely on vsyscall use will be terminated regardless of the filter program policy

Re: /dev/urandom uses uninit bytes, leaks user data

On Dec 20, 2007 3:17 PM, Phillip Susi <[EMAIL PROTECTED]> wrote: > Andrew Lutomirski wrote: > > I understand that there's no way that /dev/random can provide good > > output if there's insufficient entropy. But it still shouldn't leak > > arbitrary bits of user

Re: /dev/urandom uses uninit bytes, leaks user data

On Dec 20, 2007 3:17 PM, Phillip Susi [EMAIL PROTECTED] wrote: Andrew Lutomirski wrote: I understand that there's no way that /dev/random can provide good output if there's insufficient entropy. But it still shouldn't leak arbitrary bits of user data that were never meant to be put

Re: /dev/urandom uses uninit bytes, leaks user data

On Dec 17, 2007 10:46 PM, Theodore Tso <[EMAIL PROTECTED]> wrote: > If you have a system with insufficent entropy inputs, you're in > trouble, of course. There are "catastrophic reseeds" that attempt to > mitigrate some of worse attacks, but at the end of the day, > /dev/random isn't magic. > I

Re: /dev/urandom uses uninit bytes, leaks user data

On Dec 17, 2007 10:46 PM, Theodore Tso [EMAIL PROTECTED] wrote: If you have a system with insufficent entropy inputs, you're in trouble, of course. There are catastrophic reseeds that attempt to mitigrate some of worse attacks, but at the end of the day, /dev/random isn't magic. I

Re: A little coding style nugget of joy

On 9/19/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > > This is a terrible assumption in general (i.e. if filesize % blocksize > > is close to uniformly distributed). If you remove one byte and the data > > is stored with blocksize B, then you either save zero bytes with > > probability 1-1/B or

Re: A little coding style nugget of joy

On 9/19/07, Andi Kleen [EMAIL PROTECTED] wrote: This is a terrible assumption in general (i.e. if filesize % blocksize is close to uniformly distributed). If you remove one byte and the data is stored with blocksize B, then you either save zero bytes with probability 1-1/B or you save B