From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 81626800D8 for ; Mon, 22 Jan 2018 05:04:11 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id r82so4774126wme.0 for ; Mon, 22 Jan 2018 02:04:11 -0800 (PST) Received: from theia.8bytes.org (8bytes.org. [2a01:238:4383:600:38bc:a715:4b6d:a889]) by mx.google.com with ESMTPS id x4si3811477edc.501.2018.01.22.02.04.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 02:04:10 -0800 (PST) Date: Mon, 22 Jan 2018 11:04:09 +0100 From: Joerg Roedel Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Message-ID: <20180122100409.GF28161@8bytes.org> References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> <7f37ff1c10b04b2386c2044cdc8e38be@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f37ff1c10b04b2386c2044cdc8e38be@AcuMS.aculab.com> Sender: owner-linux-mm@kvack.org List-ID: To: David Laight Cc: 'Nadav Amit' , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Linus Torvalds , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "aliguori@amazon.com" , "daniel.gruss@iaik.tugraz.at" , "hughd@google.com" , "keescook@google.com" , Andrea Arcangeli , Waiman Long , "jroedel@suse.de" On Mon, Jan 22, 2018 at 09:55:31AM +0000, David Laight wrote: > That's made me remember something about segment limits applying in 64bit mode. > I really can't remember the details at all. > I'm sure it had something to do with one of the VM implementations restricting > memory accesses. Some AMD chips have long-mode segment limits, not sure if Intel has them too. But they are useless here because the limit is 32 bit and can only protect the upper 4GB of virtual address space. The limits also don't apply to GS and CS segements. Regards, Joerg -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227fTNaQKwnF7VuBpZ5n3ala9iJmy96nlOeGIRwNaieO4Hr18Az7yOsKQHcV5cTpy7xqfnlg ARC-Seal: i=1; a=rsa-sha256; t=1516615450; cv=none; d=google.com; s=arc-20160816; b=zPOJS0fkLHpqXClqwQ4YdzDTm1p5mZQEuJt805dR0obvPadt+2VP9DAfirx2XAy4Xw uste3C9JTVcOLDra4/2Qo5jupbkZ+iq7cHlqYXm7efKyBH2NDpUq0paw7Axs0WPNmMS8 WywIrUZkuyMdj6OkVIY3/vGDAi8rTS66i8UA7X8eTuzMekUzeOzEqe/e61LcZ4msEIfE wYtcGHLY8BaAyfLXxZ9oZaHgMLwQADdIB/pq40opJlNzx9l8d1ghMSX89mLyFZL4ZRPf pJCQjSM3tPsZP+tkN5DPUZ/QW8pNGeFA74rLJh7gE70vPmcHARK0GtLR7fevjp0nsDZj dTKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=qSdWsCcNH1vhHEBevhm0tQB5AqbhDl7jMR6G7V6yTiQ=; b=FqUixgHOhre+n2mW1AGLLUHSX628Z+7grp5K5R12dHUL3bSzFZOs6+wEr44GS2v38Z dVS84fDeou8312PVYnnQW1oVuC/ivEB0jLjaLeBWWm3YkBbHWUEKrzdujLEAaRhvAZGc zJJeDt+A+IVU0ggwA52ntHTK+9jL6PAWA9fIj2SBq7A/pCJHfTE5UOU7NDUaLHW044or GuzSRP4qG/KltvGC/gWONxg2yXZdeG4qtryda3c89W2/bv6dWzb/ji9Ncm8EBM6kE3Z5 zFEfwGyf+OaK1wVOIBmpuSXxTpCN56ZUKbQP6Wvurall5ckK76tdJBXNld3vaqmLKWHK wtaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@8bytes.org header.s=mail-1 header.b=C+MpY9Ol; spf=pass (google.com: domain of joro@8bytes.org designates 2a01:238:4383:600:38bc:a715:4b6d:a889 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@8bytes.org header.s=mail-1 header.b=C+MpY9Ol; spf=pass (google.com: domain of joro@8bytes.org designates 2a01:238:4383:600:38bc:a715:4b6d:a889 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Date: Mon, 22 Jan 2018 11:04:09 +0100 From: Joerg Roedel To: David Laight Cc: 'Nadav Amit' , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Linus Torvalds , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "aliguori@amazon.com" , "daniel.gruss@iaik.tugraz.at" , "hughd@google.com" , "keescook@google.com" , Andrea Arcangeli , Waiman Long , "jroedel@suse.de" Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Message-ID: <20180122100409.GF28161@8bytes.org> References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> <7f37ff1c10b04b2386c2044cdc8e38be@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f37ff1c10b04b2386c2044cdc8e38be@AcuMS.aculab.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841591470697?= X-GMAIL-MSGID: =?utf-8?q?1590286562691440649?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 22, 2018 at 09:55:31AM +0000, David Laight wrote: > That's made me remember something about segment limits applying in 64bit mode. > I really can't remember the details at all. > I'm sure it had something to do with one of the VM implementations restricting > memory accesses. Some AMD chips have long-mode segment limits, not sure if Intel has them too. But they are useless here because the limit is 32 bit and can only protect the upper 4GB of virtual address space. The limits also don't apply to GS and CS segements. Regards, Joerg