diff for duplicates of <39ea6607-a013-bd18-b478-3f44fb17caa4@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index f2a4b9d..d69ed32 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,7 +13,7 @@ On 11/23/2017 04:38 AM, Florian Weimer wrote: >>>>>> not?), so should we also document it? >>>>> >>>>> I think the -1 case to the set the default key is useful because it ->>>>> allows you to use a key value of -1 to mean “MPK is not supported”, +>>>>> allows you to use a key value of -1 to mean a??MPK is not supporteda??, >>>>> and >>>>> still call pkey_mprotect. >>>> @@ -23,14 +23,14 @@ On 11/23/2017 04:38 AM, Florian Weimer wrote: >>> On the other hand, x86-64 has no single default protection key due to >>> the PROT_EXEC emulation. >> ->> No, the default is clearly 0 and documented to be so. The PROT_EXEC +>> No, the default is clearly 0 and documented to be so.A The PROT_EXEC >> emulation one should be inaccessible in all the APIs so does not even >> show up as *being* a key in the API. I should have been more explicit: the EXEC pkey does not show up in the syscall API. -> I see key 1 in /proc for a PROT_EXEC mapping. If I supply an explicit +> I see key 1 in /proc for a PROT_EXEC mapping.A If I supply an explicit > protection key, that key is used, and the page ends up having read > access enabled. > @@ -38,9 +38,9 @@ syscall API. > PROT_EXEC mapping with the default key, so it's not just /proc: > > page 1 (0x7f008242d000): read access denied -> SIGSEGV address: 0x7f008242d000 -> SIGSEGV code: 4 -> SIGSEGV key: 1 +> A SIGSEGV address: 0x7f008242d000 +> A SIGSEGV code: 4 +> A SIGSEGV key: 1 > > I'm attaching my test. @@ -53,7 +53,7 @@ If that behavior is broken, we should probably fix it. >> with pkeys should be pretty immaterial other than the fact that you >> can't touch the high bits in PKRU. > -> I don't see a restriction for PKRU updates. If I write zero to the PKRU +> I don't see a restriction for PKRU updates.A If I write zero to the PKRU > register, PROT_EXEC implies PROT_READ, as I would expect. I'll rephrase: @@ -63,3 +63,9 @@ I'll rephrase: controlling PROT_EXEC in PKRU if you want to keep it working. There is no restriction which is *enforced*. It's just documented. + +-- +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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 75e324a..404ea69 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -31,7 +31,7 @@ ">>>>>> not?), so should we also document it?\n" ">>>>>\n" ">>>>> I think the -1 case to the set the default key is useful because it\n" - ">>>>> allows you to use a key value of -1 to mean \342\200\234MPK is not supported\342\200\235,\n" + ">>>>> allows you to use a key value of -1 to mean a??MPK is not supporteda??,\n" ">>>>> and\n" ">>>>> still call pkey_mprotect.\n" ">>>>\n" @@ -41,14 +41,14 @@ ">>> On the other hand, x86-64 has no single default protection key due to\n" ">>> the PROT_EXEC emulation.\n" ">>\n" - ">> No, the default is clearly 0 and documented to be so.\302\240 The PROT_EXEC\n" + ">> No, the default is clearly 0 and documented to be so.A The PROT_EXEC\n" ">> emulation one should be inaccessible in all the APIs so does not even\n" ">> show up as *being* a key in the API.\n" "\n" "I should have been more explicit: the EXEC pkey does not show up in the\n" "syscall API.\n" "\n" - "> I see key 1 in /proc for a PROT_EXEC mapping.\302\240 If I supply an explicit\n" + "> I see key 1 in /proc for a PROT_EXEC mapping.A If I supply an explicit\n" "> protection key, that key is used, and the page ends up having read\n" "> access enabled.\n" "> \n" @@ -56,9 +56,9 @@ "> PROT_EXEC mapping with the default key, so it's not just /proc:\n" "> \n" "> page 1 (0x7f008242d000): read access denied\n" - "> \302\240 SIGSEGV address: 0x7f008242d000\n" - "> \302\240 SIGSEGV code: 4\n" - "> \302\240 SIGSEGV key: 1\n" + "> A SIGSEGV address: 0x7f008242d000\n" + "> A SIGSEGV code: 4\n" + "> A SIGSEGV key: 1\n" "> \n" "> I'm attaching my test.\n" "\n" @@ -71,7 +71,7 @@ ">> with pkeys should be pretty immaterial other than the fact that you\n" ">> can't touch the high bits in PKRU.\n" "> \n" - "> I don't see a restriction for PKRU updates.\302\240 If I write zero to the PKRU\n" + "> I don't see a restriction for PKRU updates.A If I write zero to the PKRU\n" "> register, PROT_EXEC implies PROT_READ, as I would expect.\n" "\n" "I'll rephrase:\n" @@ -80,6 +80,12 @@ "\timmaterial other than the fact that you must not touch the bits\n" "\tcontrolling PROT_EXEC in PKRU if you want to keep it working.\n" "\n" - There is no restriction which is *enforced*. It's just documented. + "There is no restriction which is *enforced*. It's just documented.\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -a2adb66ee6e347c80cfeb4beb25c34d4493ffcb4e5e108a357e9e068c319b95f +d7187aafc7a39fefc37864d76fa82f74b29038a84720550be9f7113efabb13f9
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.