Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

2017-11-30 Thread joeyli
Hi James, First, thank you for reviewing and comment! On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote: > On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote: > > The mok can not be trusted when the secure boot is disabled. Which > > means that the kernel embedded certificate

Re: [GIT PULL] hash addresses printed with %p

2017-11-30 Thread Linus Torvalds
On Thu, Nov 30, 2017 at 12:10 PM, Greg Kroah-Hartman wrote: > > So changing it to use __ATTR() should fix this remaning leakage up. > That is if we even really need to export these values at all. What does > userspace do with them? Shouldn't they just be in debugfs

Re: [GIT PULL] hash addresses printed with %p

2017-11-30 Thread Ard Biesheuvel
On 30 November 2017 at 17:10, Greg Kroah-Hartman wrote: > On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote: >> On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote: >> > On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds >> >

Re: [GIT PULL] hash addresses printed with %p

2017-11-30 Thread Greg Kroah-Hartman
On Thu, Nov 30, 2017 at 04:32:35PM +, Greg Kroah-Hartman wrote: > On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote: > > On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds > > wrote: > > > > > > Not because %pK itself changed, but because the semantics

Re: [GIT PULL] hash addresses printed with %p

2017-11-30 Thread Greg Kroah-Hartman
On Wed, Nov 29, 2017 at 01:36:25PM -0800, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 1:14 PM, Linus Torvalds > wrote: > > > > Not because %pK itself changed, but because the semantics of %p did. > > The baseline moved, and the "safe" version did not. > > Btw,

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

2017-11-30 Thread James Bottomley
On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote: > The mok can not be trusted when the secure boot is disabled. Which > means that the kernel embedded certificate is the only trusted key. > > Due to db/dbx are authenticated variables, they needs manufacturer's > KEK for update. So db/dbx

[PATCH v5 19/27] x86: assembly, make some functions local

2017-11-30 Thread Jiri Slaby
There is a couple of assembly functions, which are invoked only locally in the file they are defined. In C, we mark them "static". In assembly, annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on ENDPROC/END for a

[PATCH v5 26/27] x86_32: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

2017-11-30 Thread Jiri Slaby
These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START (and their ENDPROC's by SYM_FUNC_END.) Now, we can finally force ENTRY/ENDPROC to be undefined on X86. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin"

[PATCH v5 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

2017-11-30 Thread Jiri Slaby
These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START. And their ENDPROC's by SYM_FUNC_END. And make sure ENTRY/ENDPROC is not defined on X86_64, given these were the last users. Signed-off-by: Jiri Slaby