Self Introduction
Per "Get Involved" on the Kernel Self Protection Project wiki, I'm introducing myself.
I have recently joined Linaro on the Security Working Group. As such, I expect to seen be getting involved with the various kernel hardening and related projects.
David Brown
Quoted 6 lines · David Brown
Per "Get Involved" on the Kernel Self Protection Project wiki, I'm introducing myself.
I have recently joined Linaro on the Security Working Group. As such, I expect to seen be getting involved with the various kernel hardening and related projects.
Hi David!
Welcome to the mailing list. :)
What sorts of things are you interested in working on?
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 11 lines · Kees Cook
Quoted 6 lines · David Brown
Per "Get Involved" on the Kernel Self Protection Project wiki, I'm introducing myself.
I have recently joined Linaro on the Security Working Group. As such, I expect to seen be getting involved with the various kernel hardening and related projects.
Welcome to the mailing list. :)
What sorts of things are you interested in working on?
A while back, I'd gone through each of the features in grsecurity and PAX. There were a number that seemed good from a security point of view, but difficult in terms of culture within the kernel. I've just started up going through these again, as well as reading the kernel hardening wiki, and I should soon have a better idea of what would be good to work on. My scope is broad enough that I want to get a good idea of where others want to go as well, as well as what brings good benefit.
I suspect part of the challenge is going to be clearly describing the various features along with specific examples of already-discovered exploits that the feature would have mitigated.
Most recently, I backported ARM PAN support to the Linaro stable kernels (3.18 and 4.1).
David
Quoted 18 lines · David Brown
Quoted 7 lines · Kees Cook
Quoted 4 lines · David Brown
Per "Get Involved" on the Kernel Self Protection Project wiki, I'm introducing myself.
Quoted 8 lines
Quoted 3 lines
I have recently joined Linaro on the Security Working Group. As such, I expect to seen be getting involved with the various kernel hardening and related projects.
Welcome to the mailing list. :)
What sorts of things are you interested in working on?
Quoted 8 lines
A while back, I'd gone through each of the features in grsecurity and PAX. There were a number that seemed good from a security point of view, but difficult in terms of culture within the kernel. I've just started up going through these again, as well as reading the kernel hardening wiki, and I should soon have a better idea of what would be good to work on. My scope is broad enough that I want to get a good idea of where others want to go as well, as well as what brings good benefit.
Great! It might be valuable to read through this mailing lists's threads over the last month. We discuss a few of the features and some work has been started.
Quoted 3 lines
I suspect part of the challenge is going to be clearly describing the various features along with specific examples of already-discovered exploits that the feature would have mitigated.
Yes indeed. :) That's why I've arranged the wiki the way I did:
classes and methods first, with potential solutions listed under them. We want to start with problem descriptions and work from actual exploits when possible.
This is why the recent x86 VDSO attack was very timely: it demonstrates cleanly why we want __ro_after_init (née __read_only) in upstream. (As well as the constification plugin.)
Quoted 2 lines
Most recently, I backported ARM PAN support to the Linaro stable kernels (3.18 and 4.1).
Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very nice to have a UDEREF-like feature on arm. It's too bad this doesn't exist for Intel yet, but I'm hoping they'll step up.
For 3.18, is this the right place to be looking?
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18
I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel too.
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 3 lines · Kees Cook
Great! It might be valuable to read through this mailing lists's threads over the last month. We discuss a few of the features and some work has been started.
Reading through stuff now. Looks like the list got quite a boost in November.
Quoted 4 lines
Quoted 3 lines
I suspect part of the challenge is going to be clearly describing the various features along with specific examples of already-discovered exploits that the feature would have mitigated.
Quoted 8 lines
Yes indeed. :) That's why I've arranged the wiki the way I did:
classes and methods first, with potential solutions listed under them. We want to start with problem descriptions and work from actual exploits when possible.This is why the recent x86 VDSO attack was very timely: it demonstrates cleanly why we want
__ro_after_init(née__read_only) in upstream. (As well as the constification plugin.)
Which also seems like this will be quite useful on ARM as well. Do you know any efforts to do this?
Quoted 9 lines
Quoted 2 lines
Most recently, I backported ARM PAN support to the Linaro stable kernels (3.18 and 4.1).
Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very nice to have a UDEREF-like feature on arm. It's too bad this doesn't exist for Intel yet, but I'm hoping they'll step up.
For 3.18, is this the right place to be looking?
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18
It will be once it gets through testing.
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN
to peek before then. There's also
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN
for the 4.1 tree.
Should I CC kernel-hardening when sending patches for the Linaro stable kernels?
Quoted 1 line
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.
I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
In fact, I don't have any hardware yet that supports PAN. I've done all of the testing in emulation.
David
Quoted 20 lines · David Brown
Quoted 3 lines · Kees Cook
Great! It might be valuable to read through this mailing lists's threads over the last month. We discuss a few of the features and some work has been started.
Reading through stuff now. Looks like the list got quite a boost in November.
Quoted 10 lines
Quoted 3 lines
I suspect part of the challenge is going to be clearly describing the various features along with specific examples of already-discovered exploits that the feature would have mitigated.
Yes indeed. :) That's why I've arranged the wiki the way I did:
classes and methods first, with potential solutions listed under them. We want to start with problem descriptions and work from actual exploits when possible.
Quoted 7 lines
Quoted 3 lines
This is why the recent x86 VDSO attack was very timely: it demonstrates cleanly why we want
__ro_after_init(née__read_only) in upstream. (As well as the constification plugin.)Which also seems like this will be quite useful on ARM as well. Do you know any efforts to do this?
I've not seen any yet. If you get it written, I can include it in my __ro_after_init series on the next revision.
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
Most recently, I backported ARM PAN support to the Linaro stable kernels (3.18 and 4.1).
Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very nice to have a UDEREF-like feature on arm. It's too bad this doesn't exist for Intel yet, but I'm hoping they'll step up.
For 3.18, is this the right place to be looking?
Quoted 8 lines
Quoted 1 line
It will be once it gets through testing.
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN
to peek before then. There's also
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN
for the 4.1 tree.
Oh! I see now. You meant hardware PAN support. Yes, also good to get in for the arm64 devices. I meant the CONFIG_CPU_SW_DOMAIN_PAN support. I've backported that from 4.3 to 4.1 since then all arm devices would gain PAN-like support too.
Quoted 2 lines
Should I CC kernel-hardening when sending patches for the Linaro stable kernels?
Probably not for stable backports. I think upstream development things probably should be, and we can certainly discuss stuff that looks like it'd be good to backport, but I wouldn't want to bore people with patch for old kernels. :)
Quoted 6 lines
Quoted 2 lines
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to CONFIG_CPU_SW_DOMAIN_PAN (or similar).
Quoted 2 lines
In fact, I don't have any hardware yet that supports PAN. I've done all of the testing in emulation.
Heh, yeah, that's how the x86 SMAP stuff is too. ;)
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 5 lines · Kees Cook
Quoted 4 lines · David Brown
Quoted 2 lines · Kees Cook
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.
Quoted 7 lines
Quoted 3 lines
I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN(or similar).
Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2
Haven't seen any follow up on it though...
Quoted 10 lines · Stephen Smalley
Quoted 9 lines · Kees Cook
Quoted 7 lines · David Brown
Quoted 2 lines · Kees Cook
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
Quoted 8 lines
Quoted 3 lines
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN(or similar).Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2Haven't seen any follow up on it though...
Ah yes! Thank you!
https://patchwork.kernel.org/patch/7250401/
https://patchwork.kernel.org/patch/7250391/
https://patchwork.kernel.org/patch/7250421/
https://patchwork.kernel.org/patch/7250441/
Catalin, where does this stand? Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if they're running 64-bit?
The matrix for PAN seems to be:
ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN
ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)
ARMv8 32-bit: Catalin's series?
ARMv8 64-bit: ??
ARMv8.1: hardware PAN
x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists) x86 Broadwell+: hardware PAN (SMAP)
powerpc: ??
MIPS: ??
Corrections appreciated. :)
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 1 line
ARMv8 64-bit: ??
The worst case scenario would be doing something like the x86_64 UDEREF.
Quoted 1 line
x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
It's worth noting that there's the pre-PCID implementation (slow and vulnerable to races) and then two choices of better implementations when PCID is available. You probably know that already, but it's not obvious to everyone else.
I've put the matrix up on the wiki here:
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
Quoted 10 lines · Daniel Micay
Quoted 1 line
ARMv8 64-bit: ??
The worst case scenario would be doing something like the
x86_64UDEREF.Quoted 1 line
x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
It's worth noting that there's the pre-PCID implementation (slow and vulnerable to races) and then two choices of better implementations when PCID is available. You probably know that already, but it's not obvious to everyone else.
Yeah. PCID was Sandybridge and later?
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 1 line
Yeah. PCID was Sandybridge and later?
Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one.
Quoted 4 lines · Daniel Micay
Quoted 1 line
Yeah. PCID was Sandybridge and later?
Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one.
Is there anyone from Intel on the list? I would love to see UDEREF ported to upstream on x86 (and the non PCID version too). No one has stepped up to work on it yet.
As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd love to update the matrix for powerpc and MIPS.
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 12 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kees Cook
Sent: Thursday, December 10, 2015 11:24 AM
To: [email protected]
Cc: Catalin Marinas <[email protected]>; PaX Team <[email protected]>; Michael Ellerman <[email protected]>; Heiko Carstens <[email protected]>; Ralf Baechle <[email protected]>
Subject: Re: [kernel-hardening] Self IntroductionOn Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <[email protected]> wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Yeah. PCID was Sandybridge and later?
Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one.
Is there anyone from Intel on the list? I would love to see UDEREF ported to upstream on x86 (and the non PCID version too). No one has stepped up to work on it yet.
Yes, we're here. There are a couple things we need to do before making commitments on things, including deciding which are the most urgent from our perspective. We will be looking at what we want to do with UDEREF.
Quoted 10 lines
As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd love to update the matrix for powerpc and MIPS.
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
-Kees
--
Kees Cook
Chrome OS & Brillo Security
Quoted 17 lines · Casey
Quoted 17 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kees Cook
Sent: Thursday, December 10, 2015 11:24 AM
To: [email protected]
Cc: Catalin Marinas <[email protected]>; PaX Team <[email protected]>; Michael Ellerman <[email protected]>; Heiko Carstens <[email protected]>; Ralf Baechle <[email protected]>
Subject: Re: [kernel-hardening] Self IntroductionQuoted 4 lines · Daniel Micay
Quoted 1 line
Yeah. PCID was Sandybridge and later?
Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one.
Quoted 8 lines
Quoted 3 lines
Is there anyone from Intel on the list? I would love to see UDEREF ported to upstream on x86 (and the non PCID version too). No one has stepped up to work on it yet.
Yes, we're here. There are a couple things we need to do before making commitments on things, including deciding which are the most urgent from our perspective. We will be looking at what we want to do with UDEREF.
That's great! Thanks for speaking up. Another area that hasn't seen any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love to see someone else take on that chunk of work.
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 5 lines · Kees Cook
On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey
That's great! Thanks for speaking up. Another area that hasn't seen any traction yet is
PAX_USERCOPY. Valdis seems to be MIA, so I'd love to see someone else take on that chunk of work.
Whoops. sorry.. I just didn't have anything in a state ready to share, and I got sidetracked by a week in the hospital (am all OK now, thankfully).
Biggest problem is just taking one big 7M patch and teasing out just the USERCOPY parts, and then re-arranging it into something that upstream will be willing to take. Just lots and lots of grunt work.
I don't suppose the grsecurity guys have a git repo where a lot of the heavy duty lifting is already done? :)
Quoted 9 lines · On Fri, Dec 11, 2015 at 9:54 AM, <[email protected]> wrote:
Quoted 5 lines · Kees Cook
On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey
That's great! Thanks for speaking up. Another area that hasn't seen any traction yet is
PAX_USERCOPY. Valdis seems to be MIA, so I'd love to see someone else take on that chunk of work.Whoops. sorry.. I just didn't have anything in a state ready to share, and I got sidetracked by a week in the hospital (am all OK now, thankfully).
Yikes! Glad you're okay. If other people have more time to dedicate to PAX_USERCOPY extraction, maybe you could help with testing? Or what do you think?
Quoted 3 lines
Biggest problem is just taking one big 7M patch and teasing out just the USERCOPY parts, and then re-arranging it into something that upstream will be willing to take. Just lots and lots of grunt work.
Yup, that's the first step in the work. Well, first is extraction, then figuring out the best way to upstream.
Quoted 2 lines
I don't suppose the grsecurity guys have a git repo where a lot of the heavy duty lifting is already done? :)
AIUI, no such thing exists. :)
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 6 lines · Kees Cook
Quoted 4 lines · Daniel Micay
Quoted 1 line
Yeah. PCID was Sandybridge and later?
Yeah, that's right. And it defaults to the strong PCID implementation, but there's also a weaker but significantly faster PCID-based one.
Quoted 8 lines
Is there anyone from Intel on the list? I would love to see UDEREF ported to upstream on x86 (and the non PCID version too). No one has stepped up to work on it yet.
As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd love to update the matrix for powerpc and MIPS.
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
The statement for s390 is correct: we always had PAN in use. It's a hardware feature simply called "Address Spaces".
The way we use it in Linux on s390 makes is impossible to access user space contents from kernel space without special instructions.
Quoted 11 lines · Kees Cook
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
Quoted 8 lines · Daniel Micay
Quoted 1 line
ARMv8 64-bit: ??
The worst case scenario would be doing something like the
x86_64UDEREF.Quoted 1 line
x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
It's worth noting that there's the pre-PCID implementation (slow and vulnerable to races)
uhm, what races? the per-cpu PGD exists for that reason, regardless of PCID.
Quoted 5 lines
Quoted 3 lines
and then two choices of better implementations when
PCID is available. You probably know that already, but it's not obvious to everyone else.Yeah. PCID was Sandybridge and later?
IIRC, it is more like Westmere and later.
Quoted 2 lines
uhm, what races? the per-cpu PGD exists for that reason, regardless of PCID.
Ah, that makes sense. So the non-strong PCID UDEREF is really just hardware acceleration for what you were already doing before.
Quoted 21 lines · Kees Cook
Quoted 10 lines · Stephen Smalley
Quoted 9 lines · Kees Cook
Quoted 7 lines · David Brown
Quoted 2 lines · Kees Cook
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
Quoted 8 lines
Quoted 3 lines
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN(or similar).Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2Haven't seen any follow up on it though...
Quoted 8 lines
Ah yes! Thank you!
https://patchwork.kernel.org/patch/7250401/
https://patchwork.kernel.org/patch/7250391/
https://patchwork.kernel.org/patch/7250421/
https://patchwork.kernel.org/patch/7250441/Catalin, where does this stand?
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.
Quoted 2 lines
Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if they're running 64-bit?
No PAN support for ARMv8.0. It could be done similarly to the 32-bit LPAE support.
Quoted 4 lines
The matrix for PAN seems to be:
ARMv7 32-bit non-LPAE:
CONFIG_CPU_SW_DOMAIN_PANARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)
Correct.
Quoted 1 line
ARMv8 32-bit: Catalin's series?
ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32 kernel.
Quoted 1 line
ARMv8 64-bit: ??
None.
Quoted 1 line
ARMv8.1: hardware PAN
Correct.
Signature · 1 line
Catalin
Quoted 29 lines · Catalin Marinas
Quoted 28 lines · Kees Cook
Quoted 10 lines · Stephen Smalley
Quoted 9 lines · Kees Cook
Quoted 7 lines · David Brown
Quoted 2 lines · Kees Cook
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
Quoted 8 lines
Quoted 3 lines
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN(or similar).Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2Haven't seen any follow up on it though...
Ah yes! Thank you!
https://patchwork.kernel.org/patch/7250401/
https://patchwork.kernel.org/patch/7250391/
https://patchwork.kernel.org/patch/7250421/
https://patchwork.kernel.org/patch/7250441/
Quoted 7 lines
Quoted 1 line
Catalin, where does this stand?
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.
Please CC this mailing list when you do. I'd like to give it a spin (and maybe other folks will too).
Quoted 18 lines
Quoted 2 lines
Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if they're running 64-bit?
No PAN support for ARMv8.0. It could be done similarly to the 32-bit LPAE support.
Quoted 4 lines
The matrix for PAN seems to be:
ARMv7 32-bit non-LPAE:
CONFIG_CPU_SW_DOMAIN_PANARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)Correct.
Quoted 1 line
ARMv8 32-bit: Catalin's series?
ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32 kernel.
Quoted 7 lines
Quoted 1 line
ARMv8 64-bit: ??
None.
Quoted 1 line
ARMv8.1: hardware PAN
Correct.
Excellent, thanks!
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 29 lines · Catalin Marinas
Quoted 28 lines · Kees Cook
Quoted 10 lines · Stephen Smalley
Quoted 9 lines · Kees Cook
Quoted 7 lines · David Brown
Quoted 2 lines · Kees Cook
I'd love to see
CONFIG_CPU_SW_DOMAIN_PANinto the AOSP 3.18 android kernel too.I'll put this on my list to investigate. Sadly, it looks like there is a bit of a window of ARM CPUs where neither solution will work; Basically the pre V8.1 64-bit.
Quoted 8 lines
Quoted 3 lines
The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN(or similar).Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2Haven't seen any follow up on it though...
Ah yes! Thank you!
https://patchwork.kernel.org/patch/7250401/
https://patchwork.kernel.org/patch/7250391/
https://patchwork.kernel.org/patch/7250421/
https://patchwork.kernel.org/patch/7250441/
Quoted 7 lines
Quoted 1 line
Catalin, where does this stand?
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.
David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)
-Kees
[1] http://lwn.net/Articles/663531/ specifically ACCESS_USERSPACE and EXEC_USERSPACE
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Quoted 3 lines · Kees Cook
David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)
I was planning on this. It's probably going to be a little while (as in January) before I have any reasonable hardware to test things on, though. I have one board I need to get working, and another is in the mail. Both, however, are A53-based, which gets all of the other configurations. I'll see if I can figure out how to get access to our test infrastructure.
I am familiar with LKDTM, and it's how I was able to test PAN easily.
Thanks,
David
Quoted 9 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)
Sorry for the delay in getting back to you. Been both moving and taking vacation.
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Thanks,
David
Quoted 14 lines · David Brown
Quoted 10 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)
Quoted 5 lines
Sorry for the delay in getting back to you. Been both moving and taking vacation.
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Awesome! Thanks for the update.
Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation?
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
+ rmk
Quoted 18 lines · Kees Cook
Quoted 17 lines · David Brown
Quoted 10 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)Sorry for the delay in getting back to you. Been both moving and taking vacation.
Quoted 8 lines
Quoted 2 lines
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Awesome! Thanks for the update.
Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation?
Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux.
The minor side effect is that the PAN may not always work. We could invalidate the TLBs at every PAN change and take a significant performance hit. However, the more serious side effect is that TLB conflicts may happen, leading to aborts (though unlikely on existing hardware but we can't guarantee it for the future). The latter can't be avoided (only reduce) by more TLB invalidation (the proper fix would be MMU disabling).
In conclusion, I'm NAK'ing my own patch ;). The alternative is to make TTBR0 point to swapper_pg_dir where there are no user mappings. The difficulty is that such patch won't fit nicely onto the existing uaccess_* macros that rmk added. It also doesn't work well with switch_mm(), we would have to defer the TTBR0 setting until returning to user space (cpu_switch_mm() should no longer be called in check_and_switch_context() as it automatically enables privileged access to user).
I haven't had time to look into re-writing the patch. Hopefully sometime in February, unless someone else volunteers to take over.
Question for Russell: do we have any guarantees that lowmem doesn't cross a 32-bit boundary? This would simplify the code a bit by preserving the top 32-bit of TTBR0 when changing. But looking at the sanity_check_meminfo(), I couldn't see anything that would guarantee this. Even the virt_to_phys() macro does a carry add for the top 32-bit.
Signature · 1 line
Catalin
+ rmk (actually cc'ing him this time)
Quoted 18 lines · Kees Cook
Quoted 17 lines · David Brown
Quoted 10 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)Sorry for the delay in getting back to you. Been both moving and taking vacation.
Quoted 8 lines
Quoted 2 lines
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Awesome! Thanks for the update.
Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation?
Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux.
The minor side effect is that the PAN may not always work. We could invalidate the TLBs at every PAN change and take a significant performance hit. However, the more serious side effect is that TLB conflicts may happen, leading to aborts (though unlikely on existing hardware but we can't guarantee it for the future). The latter can't be avoided (only reduce) by more TLB invalidation (the proper fix would be MMU disabling).
In conclusion, I'm NAK'ing my own patch ;). The alternative is to make TTBR0 point to swapper_pg_dir where there are no user mappings. The difficulty is that such patch won't fit nicely onto the existing uaccess_* macros that rmk added. It also doesn't work well with switch_mm(), we would have to defer the TTBR0 setting until returning to user space (cpu_switch_mm() should no longer be called in check_and_switch_context() as it automatically enables privileged access to user).
I haven't had time to look into re-writing the patch. Hopefully sometime in February, unless someone else volunteers to take over.
Question for Russell: do we have any guarantees that lowmem doesn't cross a 32-bit boundary? This would simplify the code a bit by preserving the top 32-bit of TTBR0 when changing. But looking at the sanity_check_meminfo(), I couldn't see anything that would guarantee this. Even the virt_to_phys() macro does a carry add for the top 32-bit.
Signature · 1 line
Catalin
Quoted 30 lines · Catalin Marinas
+ rmk (actually cc'ing him this time)
Quoted 18 lines · Kees Cook
Quoted 17 lines · David Brown
Quoted 10 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)Sorry for the delay in getting back to you. Been both moving and taking vacation.
Quoted 8 lines
Quoted 2 lines
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Awesome! Thanks for the update.
Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation?
Quoted 6 lines
Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux.
[...]
Could you whitelist the cores where this is known to work as intended? Or is it not practical to enable/disable this PAN implementation at boot time?
Ben.
Quoted 35 lines · Ben Hutchings
Quoted 28 lines · Catalin Marinas
Quoted 18 lines · Kees Cook
Quoted 17 lines · David Brown
Quoted 10 lines · Kees Cook
Quoted 5 lines
I haven't done any further improvements to them, nor have I received any feedback. I'll rebase them against latest kernel if anyone else is willing to test. I had a plan to run some benchmarks and see how performance is affected (including the
CPU_SW_DOMAIN_PAN) before pushing again for upstreaming but I haven't had the time.David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on real hardware? (Are you familiar with the LKDTM tests for this[1]?)Sorry for the delay in getting back to you. Been both moving and taking vacation.
Quoted 8 lines
Quoted 2 lines
I'd like to test this. I'm just trying to see if I can track down some hardware that'll boot LPAE.
Awesome! Thanks for the update.
Catalin, did you end up figuring out if your TTBR0 stuff was correct? You'd mentioned you needed to check something about the implementation?
Quoted 6 lines
Unfortunately, I checked with the ARM architecture folk. While the trick is probably fine on existing hardware, the architecture allows caching of the TTBCR bits (or their effect) in the TLB. Therefore changing the TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed to have an effect until the TLBs are invalidated. CPU implementations are allowed to rely on this, so we can't safely use it in Linux.
Quoted 3 lines
[...]
Could you whitelist the cores where this is known to work as intended?
Even this information is hard to get accurately. You would have to ask the micro-architects (and not all are ARM Ltd) about the details as these are not usually publicly available. So in Linux we aim as much as possible to stick to the architecture specification rather than individual implementations, with a few exceptions for features documented in the CPU TRM (or errata docs).
Quoted 2 lines
Or is it not practical to enable/disable this PAN implementation at boot time?
Some boot-time code patching may do but we should rather do it properly by using a reserved TTBR0.
Signature · 1 line
Catalin