Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices
On Wed, Oct 04, 2017 at 01:51:13PM +0300, Jarkko Sakkinen wrote: > On Fri, Sep 29, 2017 at 08:16:17PM +0300, Jarkko Sakkinen wrote: > > On Tue, Sep 26, 2017 at 02:49:31PM +0200, Thiebaud Weksteen wrote: > > > On Tue, Sep 26, 2017 at 1:45 PM, Jarkko Sakkinen > > >wrote: > > > > On Wed, Sep 20, 2017 at 10:13:39AM +0200, Thiebaud Weksteen wrote: > > > >> With TPM 2.0 specification, the event logs may only be accessible by > > > >> calling an EFI Boot Service. Modify the EFI stub to copy the log area > > > >> to > > > >> a new Linux-specific EFI configuration table so it remains accessible > > > >> once booted. > > > >> > > > >> When calling this service, it is possible to specify the expected > > > >> format > > > >> of the logs: TPM 1.2 (SHA1) or TPM 2.0 ("Crypto Agile"). For now, only > > > >> the > > > >> first format is retrieved. > > > >> > > > >> Signed-off-by: Thiebaud Weksteen > > > > > > > > Does not apply: > > > > > > > > Applying: tpm: move tpm_eventlog.h outside of drivers folder > > > > Applying: tpm: rename event log provider files > > > > Applying: tpm: add event log format version > > > > Applying: efi: call get_event_log before ExitBootServices > > > > error: sha1 information is lacking or useless > > > > (drivers/firmware/efi/efi.c). > > > > error: could not build fake ancestor > > > > Patch failed at 0004 efi: call get_event_log before ExitBootServices > > > > The copy of the patch that failed is found in: .git/rebase-apply/patch > > > > When you have resolved this problem, run "git am --continue". > > > > If you prefer to skip this patch, run "git am --skip" instead. > > > > To restore the original branch and stop patching, run "git am --abort". > > > > > > > > Just rebased my tree to the latest security-next. > > > > > > It applies fine on security/next-general which is more up-to-date. > > > (security/next does not include > > > ccc829ba3624beb9a703fc995d016b836d9eead8 on which this patch set is > > > based) > > > > Thanks, my bad, I though that I had it updated. > > > > I'll update my tree and retry. > > > > /Jarkko > > My master is up to date with security/next. > > Still get the same result: > > $ git am -3 > ~/Downloads/v3-4-5-efi-call-get_event_log-before-ExitBootServices.patch > Applying: efi: call get_event_log before ExitBootServices > error: sha1 information is lacking or useless (drivers/firmware/efi/efi.c). > error: could not build fake ancestor > Patch failed at 0001 efi: call get_event_log before ExitBootServices > The copy of the patch that failed is found in: .git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > Maybe you have some other trees fetched in your local GIT so that it > finds the ancestors? Anyway, cannot test this at this point. > > /Jarkko I pushed the first three patches to my master as they looked OK. You should still consider them unreviewed. /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices
On Wed, Oct 4, 2017 at 12:51 PM, Jarkko Sakkinenwrote: > On Fri, Sep 29, 2017 at 08:16:17PM +0300, Jarkko Sakkinen wrote: >> On Tue, Sep 26, 2017 at 02:49:31PM +0200, Thiebaud Weksteen wrote: >> > On Tue, Sep 26, 2017 at 1:45 PM, Jarkko Sakkinen >> > wrote: >> > > On Wed, Sep 20, 2017 at 10:13:39AM +0200, Thiebaud Weksteen wrote: >> > >> With TPM 2.0 specification, the event logs may only be accessible by >> > >> calling an EFI Boot Service. Modify the EFI stub to copy the log area to >> > >> a new Linux-specific EFI configuration table so it remains accessible >> > >> once booted. >> > >> >> > >> When calling this service, it is possible to specify the expected format >> > >> of the logs: TPM 1.2 (SHA1) or TPM 2.0 ("Crypto Agile"). For now, only >> > >> the >> > >> first format is retrieved. >> > >> >> > >> Signed-off-by: Thiebaud Weksteen >> > > >> > > Does not apply: >> > > >> > > Applying: tpm: move tpm_eventlog.h outside of drivers folder >> > > Applying: tpm: rename event log provider files >> > > Applying: tpm: add event log format version >> > > Applying: efi: call get_event_log before ExitBootServices >> > > error: sha1 information is lacking or useless >> > > (drivers/firmware/efi/efi.c). >> > > error: could not build fake ancestor >> > > Patch failed at 0004 efi: call get_event_log before ExitBootServices >> > > The copy of the patch that failed is found in: .git/rebase-apply/patch >> > > When you have resolved this problem, run "git am --continue". >> > > If you prefer to skip this patch, run "git am --skip" instead. >> > > To restore the original branch and stop patching, run "git am --abort". >> > > >> > > Just rebased my tree to the latest security-next. >> > >> > It applies fine on security/next-general which is more up-to-date. >> > (security/next does not include >> > ccc829ba3624beb9a703fc995d016b836d9eead8 on which this patch set is >> > based) >> >> Thanks, my bad, I though that I had it updated. >> >> I'll update my tree and retry. >> >> /Jarkko > > My master is up to date with security/next. > > Still get the same result: > > $ git am -3 > ~/Downloads/v3-4-5-efi-call-get_event_log-before-ExitBootServices.patch > Applying: efi: call get_event_log before ExitBootServices > error: sha1 information is lacking or useless (drivers/firmware/efi/efi.c). > error: could not build fake ancestor > Patch failed at 0001 efi: call get_event_log before ExitBootServices > The copy of the patch that failed is found in: .git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > Maybe you have some other trees fetched in your local GIT so that it > finds the ancestors? Anyway, cannot test this at this point. > > /Jarkko The security/next branch still does not contain the commit I mentioned (ccc829ba3624beb9a703fc995d016b836d9eead8), which is already part of torvalds/master now. $ git branch -a --contains ccc829ba3624beb9a703fc995d016b836d9eead8 efi_tpm2_eventlog master remotes/linux-next/akpm remotes/linux-next/akpm-base remotes/linux-next/master remotes/linux-next/stable remotes/security/fixes-v4.14-rc3 remotes/security/fixes-v4.14-rc4 remotes/security/next-general remotes/security/next-testing remotes/torvalds/master Is there any reason why you are trying to merge on that specific branch and not next-general or next-testing? Would you know the purpose of all these next-* branches? Thanks, Thiebaud -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices
On Fri, Sep 29, 2017 at 08:16:17PM +0300, Jarkko Sakkinen wrote: > On Tue, Sep 26, 2017 at 02:49:31PM +0200, Thiebaud Weksteen wrote: > > On Tue, Sep 26, 2017 at 1:45 PM, Jarkko Sakkinen > >wrote: > > > On Wed, Sep 20, 2017 at 10:13:39AM +0200, Thiebaud Weksteen wrote: > > >> With TPM 2.0 specification, the event logs may only be accessible by > > >> calling an EFI Boot Service. Modify the EFI stub to copy the log area to > > >> a new Linux-specific EFI configuration table so it remains accessible > > >> once booted. > > >> > > >> When calling this service, it is possible to specify the expected format > > >> of the logs: TPM 1.2 (SHA1) or TPM 2.0 ("Crypto Agile"). For now, only > > >> the > > >> first format is retrieved. > > >> > > >> Signed-off-by: Thiebaud Weksteen > > > > > > Does not apply: > > > > > > Applying: tpm: move tpm_eventlog.h outside of drivers folder > > > Applying: tpm: rename event log provider files > > > Applying: tpm: add event log format version > > > Applying: efi: call get_event_log before ExitBootServices > > > error: sha1 information is lacking or useless > > > (drivers/firmware/efi/efi.c). > > > error: could not build fake ancestor > > > Patch failed at 0004 efi: call get_event_log before ExitBootServices > > > The copy of the patch that failed is found in: .git/rebase-apply/patch > > > When you have resolved this problem, run "git am --continue". > > > If you prefer to skip this patch, run "git am --skip" instead. > > > To restore the original branch and stop patching, run "git am --abort". > > > > > > Just rebased my tree to the latest security-next. > > > > It applies fine on security/next-general which is more up-to-date. > > (security/next does not include > > ccc829ba3624beb9a703fc995d016b836d9eead8 on which this patch set is > > based) > > Thanks, my bad, I though that I had it updated. > > I'll update my tree and retry. > > /Jarkko My master is up to date with security/next. Still get the same result: $ git am -3 ~/Downloads/v3-4-5-efi-call-get_event_log-before-ExitBootServices.patch Applying: efi: call get_event_log before ExitBootServices error: sha1 information is lacking or useless (drivers/firmware/efi/efi.c). error: could not build fake ancestor Patch failed at 0001 efi: call get_event_log before ExitBootServices The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Maybe you have some other trees fetched in your local GIT so that it finds the ancestors? Anyway, cannot test this at this point. /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 19/27] x86: assembly, make some functions local
Hello Jiri, On 4 October 2017 at 08:22, Jiri Slabywrote: > On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote: >> On 2 October 2017 at 10:12, Jiri Slaby wrote: >>> 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 particular function (C or non-C). >>> >> >> I wasn't cc'ed on the cover letter, so I am missing the rationale of >> replacing ENTRY/ENDPROC with other macros. > > There was no cover letter. I am attaching what is in PATCH 1/27 instead: > Introduce new C macros for annotations of functions and data in > assembly. There is a long-standing mess in macros like ENTRY, END, > ENDPROC and similar. They are used in different manners and sometimes > incorrectly. > I must say, I don't share this sentiment. In arm64, we use ENTRY/ENDPROC for functions with external linkage, and the bare symbol name/ENDPROC for functions with local linkage. I guess we could add ENDOBJECT if we wanted to, but we never really felt the need. > So introduce macros with clear use to annotate assembly as follows: > > a) Support macros for the ones below >SYM_T_FUNC -- type used by assembler to mark functions >SYM_T_OBJECT -- type used by assembler to mark data >SYM_T_NONE -- type used by assembler to mark entries of unknown type > Is is necessary to mark an entry as having no type? What is the default type for an unmarked entry? >They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE >respectively. According to the gas manual, this is the most portable >way. I am not sure about other assemblers, so we can switch this back >to %function and %object if this turns into a problem. Architectures >can also override them by something like ", @function" if they need. > >SYM_A_ALIGN, SYM_A_NONE -- align the symbol? >SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols > Linkage != visibility > b) Mostly internal annotations, used by the ones below >SYM_ENTRY -- use only if you have to (for non-paired symbols) >SYM_START -- use only if you have to (for paired symbols) >SYM_END -- use only if you have to (for paired symbols) > > c) Annotations for code >SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for > one function >SYM_FUNC_START_ALIAS -- use where there are two global names for one > function >SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function > >SYM_FUNC_START -- use for global functions >SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment >SYM_FUNC_START_LOCAL -- use for local functions >SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o > alignment >SYM_FUNC_START_WEAK -- use for weak functions >SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment >SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START, > SYM_FUNC_START_WEAK, ... > >SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions >SYM_FUNC_INNER_LABEL_NOALIGN -- only for labels in the middle of > functions, w/o alignment > >For functions with special (non-C) calling conventions: >SYM_CODE_START -- use for non-C (special) functions >SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o > alignment >SYM_CODE_START_LOCAL -- use for local non-C (special) functions >SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special) > functions, w/o alignment >SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START > >SYM_CODE_INNER_LABEL -- only for labels in the middle of code >SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code > > d) For data >SYM_DATA_START -- global data symbol >SYM_DATA_END -- the end of the SYM_DATA_START symbol >SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol >SYM_DATA_SIMPLE -- start+end wrapper around simple global data >SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data > I am sorry but I think this is terrible. Do we really need 20+ new macros to wrap every single assembler directive involved in defining symbols and setting their attributes? Is this issue you are solving widely perceived as a problem? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 19/27] x86: assembly, make some functions local
On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote: > On 2 October 2017 at 10:12, Jiri Slabywrote: >> 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 particular function (C or non-C). >> > > I wasn't cc'ed on the cover letter, so I am missing the rationale of > replacing ENTRY/ENDPROC with other macros. There was no cover letter. I am attaching what is in PATCH 1/27 instead: Introduce new C macros for annotations of functions and data in assembly. There is a long-standing mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros for the ones below SYM_T_FUNC -- type used by assembler to mark functions SYM_T_OBJECT -- type used by assembler to mark data SYM_T_NONE -- type used by assembler to mark entries of unknown type They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE respectively. According to the gas manual, this is the most portable way. I am not sure about other assemblers, so we can switch this back to %function and %object if this turns into a problem. Architectures can also override them by something like ", @function" if they need. SYM_A_ALIGN, SYM_A_NONE -- align the symbol? SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols b) Mostly internal annotations, used by the ones below SYM_ENTRY -- use only if you have to (for non-paired symbols) SYM_START -- use only if you have to (for paired symbols) SYM_END -- use only if you have to (for paired symbols) c) Annotations for code SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for one function SYM_FUNC_START_ALIAS -- use where there are two global names for one function SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function SYM_FUNC_START -- use for global functions SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment SYM_FUNC_START_LOCAL -- use for local functions SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment SYM_FUNC_START_WEAK -- use for weak functions SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START, SYM_FUNC_START_WEAK, ... SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions SYM_FUNC_INNER_LABEL_NOALIGN -- only for labels in the middle of functions, w/o alignment For functions with special (non-C) calling conventions: SYM_CODE_START -- use for non-C (special) functions SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o alignment SYM_CODE_START_LOCAL -- use for local non-C (special) functions SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special) functions, w/o alignment SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START SYM_CODE_INNER_LABEL -- only for labels in the middle of code SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code d) For data SYM_DATA_START -- global data symbol SYM_DATA_END -- the end of the SYM_DATA_START symbol SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol SYM_DATA_SIMPLE -- start+end wrapper around simple global data SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data == The macros allow to pair starts and ends of functions and mark functions correctly in the output ELF objects. All users of the old macros in x86 are converted to use these in further patches. thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html