From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: kernel-hardening@lists.openwall.com Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, David Brown <david.brown@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Kees Cook <keescook@chromium.org> Subject: Re: [kernel-hardening] [PATCH] arm64: vdso: Mark vDSO code as read-only Date: Thu, 11 Feb 2016 15:19:20 +0100 [thread overview] Message-ID: <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com> (raw) In-Reply-To: <1455141142-6838-1-git-send-email-david.brown@linaro.org> Hi David, Nice find! On 10 February 2016 at 22:52, David Brown <david.brown@linaro.org> wrote: > Although the arm64 vDSO is cleanly separated by code/data with the > code being read-only in userspace mappings, the code page is still > writable from the kernel. There have been exploits (such as > http://itszn.com/blog/?p=21) that take advantage of this on x86 to go > from a bad kernel write to full root. > > Prevent this specific exploit on arm64 by putting the vDSO code page > in read-only memory as well. > > Before the change: > [ 3.138366] vdso: 2 pages (1 code @ ffffffc000a71000, 1 data @ ffffffc000a70000) > ---[ Kernel Mapping ]--- > 0xffffffc000000000-0xffffffc000082000 520K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000082000-0xffffffc000200000 1528K ro x SHD AF UXN MEM/NORMAL > 0xffffffc000200000-0xffffffc000800000 6M ro x SHD AF BLK UXN MEM/NORMAL > 0xffffffc000800000-0xffffffc0009b6000 1752K ro x SHD AF UXN MEM/NORMAL > 0xffffffc0009b6000-0xffffffc000c00000 2344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000c00000-0xffffffc008000000 116M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc00c000000-0xffffffc07f000000 1840M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc800000000-0xffffffc840000000 1G RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc840000000-0xffffffc87ae00000 942M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87ae00000-0xffffffc87ae70000 448K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af80000-0xffffffc87af8a000 40K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af8b000-0xffffffc87b000000 468K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87b000000-0xffffffc87fe00000 78M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87fe00000-0xffffffc87ff50000 1344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87ff90000-0xffffffc87ffa0000 64K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87fff0000-0xffffffc880000000 64K RW NX SHD AF UXN MEM/NORMAL > > After: > [ 3.138368] vdso: 2 pages (1 code @ ffffffc0006de000, 1 data @ ffffffc000a74000) > ---[ Kernel Mapping ]--- > 0xffffffc000000000-0xffffffc000082000 520K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000082000-0xffffffc000200000 1528K ro x SHD AF UXN MEM/NORMAL > 0xffffffc000200000-0xffffffc000800000 6M ro x SHD AF BLK UXN MEM/NORMAL > 0xffffffc000800000-0xffffffc0009b8000 1760K ro x SHD AF UXN MEM/NORMAL > 0xffffffc0009b8000-0xffffffc000c00000 2336K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000c00000-0xffffffc008000000 116M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc00c000000-0xffffffc07f000000 1840M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc800000000-0xffffffc840000000 1G RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc840000000-0xffffffc87ae00000 942M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87ae00000-0xffffffc87ae70000 448K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af80000-0xffffffc87af8a000 40K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af8b000-0xffffffc87b000000 468K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87b000000-0xffffffc87fe00000 78M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87fe00000-0xffffffc87ff50000 1344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87ff90000-0xffffffc87ffa0000 64K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87fff0000-0xffffffc880000000 64K RW NX SHD AF UXN MEM/NORMAL > > Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the > PaX Team, Brad Spengler, and Kees Cook. > > Signed-off-by: David Brown <david.brown@linaro.org> > --- > arch/arm64/kernel/vdso/vdso.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S > index 60c1db5..db7c0f2 100644 > --- a/arch/arm64/kernel/vdso/vdso.S > +++ b/arch/arm64/kernel/vdso/vdso.S > @@ -24,6 +24,7 @@ > __PAGE_ALIGNED_DATA ^^ You can get rid of this now as well Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > .globl vdso_start, vdso_end > + .section .rodata > .balign PAGE_SIZE > vdso_start: > .incbin "arch/arm64/kernel/vdso/vdso.so" > -- > 2.7.1 >
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [kernel-hardening] [PATCH] arm64: vdso: Mark vDSO code as read-only Date: Thu, 11 Feb 2016 15:19:20 +0100 [thread overview] Message-ID: <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com> (raw) In-Reply-To: <1455141142-6838-1-git-send-email-david.brown@linaro.org> Hi David, Nice find! On 10 February 2016 at 22:52, David Brown <david.brown@linaro.org> wrote: > Although the arm64 vDSO is cleanly separated by code/data with the > code being read-only in userspace mappings, the code page is still > writable from the kernel. There have been exploits (such as > http://itszn.com/blog/?p=21) that take advantage of this on x86 to go > from a bad kernel write to full root. > > Prevent this specific exploit on arm64 by putting the vDSO code page > in read-only memory as well. > > Before the change: > [ 3.138366] vdso: 2 pages (1 code @ ffffffc000a71000, 1 data @ ffffffc000a70000) > ---[ Kernel Mapping ]--- > 0xffffffc000000000-0xffffffc000082000 520K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000082000-0xffffffc000200000 1528K ro x SHD AF UXN MEM/NORMAL > 0xffffffc000200000-0xffffffc000800000 6M ro x SHD AF BLK UXN MEM/NORMAL > 0xffffffc000800000-0xffffffc0009b6000 1752K ro x SHD AF UXN MEM/NORMAL > 0xffffffc0009b6000-0xffffffc000c00000 2344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000c00000-0xffffffc008000000 116M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc00c000000-0xffffffc07f000000 1840M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc800000000-0xffffffc840000000 1G RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc840000000-0xffffffc87ae00000 942M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87ae00000-0xffffffc87ae70000 448K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af80000-0xffffffc87af8a000 40K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af8b000-0xffffffc87b000000 468K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87b000000-0xffffffc87fe00000 78M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87fe00000-0xffffffc87ff50000 1344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87ff90000-0xffffffc87ffa0000 64K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87fff0000-0xffffffc880000000 64K RW NX SHD AF UXN MEM/NORMAL > > After: > [ 3.138368] vdso: 2 pages (1 code @ ffffffc0006de000, 1 data @ ffffffc000a74000) > ---[ Kernel Mapping ]--- > 0xffffffc000000000-0xffffffc000082000 520K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000082000-0xffffffc000200000 1528K ro x SHD AF UXN MEM/NORMAL > 0xffffffc000200000-0xffffffc000800000 6M ro x SHD AF BLK UXN MEM/NORMAL > 0xffffffc000800000-0xffffffc0009b8000 1760K ro x SHD AF UXN MEM/NORMAL > 0xffffffc0009b8000-0xffffffc000c00000 2336K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc000c00000-0xffffffc008000000 116M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc00c000000-0xffffffc07f000000 1840M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc800000000-0xffffffc840000000 1G RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc840000000-0xffffffc87ae00000 942M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87ae00000-0xffffffc87ae70000 448K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af80000-0xffffffc87af8a000 40K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87af8b000-0xffffffc87b000000 468K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87b000000-0xffffffc87fe00000 78M RW NX SHD AF BLK UXN MEM/NORMAL > 0xffffffc87fe00000-0xffffffc87ff50000 1344K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87ff90000-0xffffffc87ffa0000 64K RW NX SHD AF UXN MEM/NORMAL > 0xffffffc87fff0000-0xffffffc880000000 64K RW NX SHD AF UXN MEM/NORMAL > > Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the > PaX Team, Brad Spengler, and Kees Cook. > > Signed-off-by: David Brown <david.brown@linaro.org> > --- > arch/arm64/kernel/vdso/vdso.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S > index 60c1db5..db7c0f2 100644 > --- a/arch/arm64/kernel/vdso/vdso.S > +++ b/arch/arm64/kernel/vdso/vdso.S > @@ -24,6 +24,7 @@ > __PAGE_ALIGNED_DATA ^^ You can get rid of this now as well Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > .globl vdso_start, vdso_end > + .section .rodata > .balign PAGE_SIZE > vdso_start: > .incbin "arch/arm64/kernel/vdso/vdso.so" > -- > 2.7.1 >
next prev parent reply other threads:[~2016-02-11 14:19 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-10 21:52 [PATCH] arm64: vdso: Mark vDSO code as read-only David Brown 2016-02-10 21:52 ` [kernel-hardening] " David Brown 2016-02-10 21:52 ` David Brown 2016-02-11 13:47 ` Will Deacon 2016-02-11 13:47 ` [kernel-hardening] " Will Deacon 2016-02-11 13:47 ` Will Deacon 2016-02-11 14:19 ` Ard Biesheuvel [this message] 2016-02-11 14:19 ` [kernel-hardening] " Ard Biesheuvel 2016-02-11 14:19 ` Ard Biesheuvel 2016-02-13 0:31 ` David Brown 2016-02-13 0:31 ` David Brown 2016-02-13 0:31 ` David Brown 2016-02-13 9:00 ` Ard Biesheuvel 2016-02-13 9:00 ` Ard Biesheuvel 2016-02-13 9:00 ` Ard Biesheuvel 2016-02-16 18:22 ` Catalin Marinas 2016-02-16 18:22 ` [kernel-hardening] " Catalin Marinas 2016-02-16 18:22 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com' \ --to=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=david.brown@linaro.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.