linux-kernel - Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2012 15:07:07 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Linda Wang <lwang@...hat.com>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

"H. Peter Anvin" <hpa@...ux.intel.com> writes:

> Supervisor Mode Access Prevention (SMAP) is a new security feature
> disclosed by Intel in revision 014 of the Intel® Architecture
> Instruction Set Extensions Programming Reference:
>
> http://software.intel.com/sites/default/files/319433-014.pdf
>
> When SMAP is active, the kernel cannot normally access pages that are
> user space (U=1).  Since the kernel does have the need to access user
> space pages under specific circumstances, an override is provided: the
> kernel can access user space pages if EFLAGS.AC=1.  For system data
> structures, e.g. descriptor tables, that are accessed by the processor
> directly, SMAP is active even in CPL 3 regardless of EFLAGS.AC.
>
> SMAP also includes two new instructions, STAC and CLAC, to flip the AC
> flag more quickly.

Have you tested kexec in this environment?

This is the kind of cpu feature that when we enable it, frequently we
have to do something on the kexec path.

At a quick skim it looks like the kexec path is using kernel page table
entries and clearing all bits from cr4 except X86_CR4_PAE so I don't
actually expect this change will require anything on the kexec path.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/