linux-kernel - Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 6 Jun 2011 23:45:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	pageexec@...email.hu, Andi Kleen <andi@...stfloor.org>,
	Andy Lutomirski <luto@....edu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to
 feature-removal-schedule


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> We *definitely* don't want to name it in a way that makes some 
> random person just turn it off because it's scary, since the random 
> person *shouldn't* turn it off today. Comprende?

Agreed, and that's fixed now.

> And the annoying part about the whole patch series is how the whole 
> re-sending has gone on forever. Just pick some approach, do it, and 
> don't even bother making it a config option for now. If we can 
> replace the vsyscall page with a page fault or int3 or whatever, 
> and it's only used for the 'time()' system call, just do it.

Ok, we can certainly remove CONFIG_LEGACY_VTIME - that would further 
simplify things!

I was unsure how big of a problem the time() slowdown was and the 
config option was easy enough to provide. My preference would be to 
just remove the config option and simplify the code - complexity is 
the #1 enemy of security.

> The series is now extended with the cleanup patches so the end 
> result looks reasonable, but why have the whole "first implement 
> it, then clean it up" and sending it as a whole series. That's 
> annoying. Just send the cleaned-up end result to begin with.

Do you think x86/vdso is worth rebasing at this stage? Right now it 
has:

 feba7e97df8c: x86-64: Rename COMPAT_VSYSCALLS to LEGACY_VTIME and clarify documentation
 7dc0452808b7: x86-64: Clean up vsyscall emulation and remove fixed-address ret
 8d6316596441: x86-64: Fix outdated comments in vsyscall_64.c
 1593843e2ada: x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS
 764611c8dfb5: x86-64, vdso, seccomp: Fix !CONFIG_SECCOMP build
 38172403a978: x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
 d55ed1d30b82: x86-64: Emulate legacy vsyscalls
 5dfcea629a08: x86-64: Fill unused parts of the vsyscall page with 0xcc
 bb5fe2f78ead: x86-64: Remove vsyscall number 3 (venosys)
 d319bb79afa4: x86-64: Map the HPET NX
 0d7b8547fb67: x86-64: Remove kernel.vsyscall64 sysctl
 9fd67b4ed071: x86-64: Give vvars their own page
 8b4777a4b50c: x86-64: Document some of entry_64.S
 6879eb2deed7: x86-64: Fix alignment of jiffies variable

it's reasonably tested by now. We'd keep about 80% of the commits 
after the rebase.

Thanks,

	Ingo
--
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/