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) &&
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 s
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 tim
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
> Signed-off
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 bit
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 u
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
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
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:
> >
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 u
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.
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:
>> >>
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
>
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:
>&
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:
>&
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 executin
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 executin
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
On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski wrote:
> 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
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 real
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 much
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
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,
>
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,
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 i
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
>&
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 sl
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 p
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 in
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 see
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 16
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
>>
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
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 Qem
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
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.
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
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
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
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. That
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 mu
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 easy.
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, whic
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)
> ||
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 an
45 matches
Mail list logo
