Re: [edk2-devel] [PATCH] EmbeddedPkg/VirtualRealTimeClockLib: Support SOURCE_DATE_EPOCH

[joeyli via groups.io]

Hi all,

On Fri, Apr 12, 2024 at 06:03:35PM +0800, joeyli via groups.io wrote:
> Hi experts,
> 
> On Fri, Apr 12, 2024 at 03:25:56PM +0800, Lee, Chun-Yi wrote:
> > From: Chun-Yi Lee 
> > 
> > RISC-V ovmf used VirtualRealTimeClockLib but the default epoch is a
> > compilation time. It causes that the RISC-V ovmf binary image is NOT
> > reproducible.
> > 
> > This patch added the support of SOURCE_DATE_EPOCH by printenv command.
> > If SOURCE_DATE_EPOCH be found then we use it as BUILD_EPOCH. Otherwise
> > we run date command for setting BUILD_EPOCH.
> > 
> > For distributions want a reproducible RISC-V ovmf image, they should
> > export SOURCE_DATE_EPOCH environment variable before building ovmf.
> > 
> > References: https://reproducible-builds.org/docs/source-date-epoch/
> > Cc: Pete Batard 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: Chun-Yi Lee 
> 
> I have filed pull request:
>  
> https://github.com/tianocore/edk2/pull/5550
> 

Does anyone have suggestion against this patch. Or I missed anything for
the submit request?

Thanks!
Joey Lee

> 
> > ---
> >  .../Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git 
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf 
> > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> > index 5d0f867..285e880 100644
> > --- 
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> > +++ 
> > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> > @@ -34,4 +34,4 @@
> >  
> >  # Current usage of this library expects GCC in a UNIX-like shell 
> > environment with the date command
> >  [BuildOptions]
> > -  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`date +%s`
> > +  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`printenv SOURCE_DATE_EPOCH || date 
> > +%s`
> > -- 
> > 2.35.3
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118444): https://edk2.groups.io/g/devel/message/118444
Mute This Topic: https://groups.io/mt/105479031/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] EmbeddedPkg/VirtualRealTimeClockLib: Support SOURCE_DATE_EPOCH

[joeyli via groups.io]

Hi experts,

On Fri, Apr 12, 2024 at 03:25:56PM +0800, Lee, Chun-Yi wrote:
> From: Chun-Yi Lee 
> 
> RISC-V ovmf used VirtualRealTimeClockLib but the default epoch is a
> compilation time. It causes that the RISC-V ovmf binary image is NOT
> reproducible.
> 
> This patch added the support of SOURCE_DATE_EPOCH by printenv command.
> If SOURCE_DATE_EPOCH be found then we use it as BUILD_EPOCH. Otherwise
> we run date command for setting BUILD_EPOCH.
> 
> For distributions want a reproducible RISC-V ovmf image, they should
> export SOURCE_DATE_EPOCH environment variable before building ovmf.
> 
> References: https://reproducible-builds.org/docs/source-date-epoch/
> Cc: Pete Batard 
> Cc: Ard Biesheuvel 
> Signed-off-by: Chun-Yi Lee 

I have filed pull request:
 
https://github.com/tianocore/edk2/pull/5550

Thanks!
Joey Lee

> ---
>  .../Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf 
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> index 5d0f867..285e880 100644
> --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> @@ -34,4 +34,4 @@
>  
>  # Current usage of this library expects GCC in a UNIX-like shell environment 
> with the date command
>  [BuildOptions]
> -  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`date +%s`
> +  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`printenv SOURCE_DATE_EPOCH || date +%s`
> -- 
> 2.35.3


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117665): https://edk2.groups.io/g/devel/message/117665
Mute This Topic: https://groups.io/mt/105479031/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/SmbiosPlatformDxe: tweak fallback release date again

[joeyli via groups.io]

Hi Laszlo,

On Tue, Mar 05, 2024 at 09:53:33AM +0100, Laszlo Ersek wrote:
> On 3/4/24 12:37, joeyli via groups.io wrote:
> > Hi,
> > 
> > On Wed, Feb 07, 2024 at 04:02:52PM +0800, joeyli via groups.io wrote:
> >> On Wed, Feb 07, 2024 at 03:55:49PM +0800, joeyli wrote:
> >>> Hi Laszlo,
> >>>
> >>> First, thanks for your review!
> >>>
> >>> On Mon, Feb 05, 2024 at 05:41:25PM +0100, Laszlo Ersek wrote:
> >>>> On 2/4/24 10:29, Lee, Chun-Yi wrote:
> >>>>> In case PcdFirmwareReleaseDateString is not set use a valid date
> >>>>> as fallback. But the default valid date can _NOT_ pass the Microsoft
> >>>>> SVVP test "Check SMBIOS Table Specific Requirements". The test emitted
> >>>>> the error message:
> >>>>>
> >>>>> BIOS Release Date string is unexpected length: 8. This string must be in
> >>>>> MM/DD/ format. No other format is allowed and no additional 
> >>>>> information
> >>>>> may be included. See field description in the SMBIOS specification.
> >>>>>
> >>>>> Base on SMBIOS spec v3.7.0:
> >>>>>
> >>>>> 08h 2.0+BIOS Release Date   BYTESTRING
> >>>>> String number of the BIOS release date. The date
> >>>>> string, if supplied, is in either mm/dd/yy or
> >>>>> mm/dd/ format. If the year portion of the string
> >>>>> is two digits, the year is assumed to be 19yy.
> >>>>> NOTE: The mm/dd/ format is required for SMBIOS
> >>>>> version 2.3 and later.
> >>>>>
> >>>>> So, let's tweek the fallback release date again.
> >>>>>
> >>>>> Fixes: a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release 
> >>>>> date") [edk2-stable202305~327]
> >>>>> Signed-off-by: "Lee, Chun-Yi" 
> >>>>> ---
> >>>>>  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> >>>>> b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> >>>>> index 0ca3776045..e929da6b81 100644
> >>>>> --- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> >>>>> +++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> >>>>> @@ -160,7 +160,7 @@ InstallAllStructures (
> >>>>>  DateStr = (CHAR16 *)FixedPcdGetPtr (PcdFirmwareReleaseDateString);
> >>>>>  DateLen = StrLen (DateStr);
> >>>>>  if (DateLen < 3) {
> >>>>> -  DateStr = L"2/2/2022";
> >>>>> +  DateStr = L"02/02/2022";
> >>>>>DateLen = StrLen (DateStr);
> >>>>>  }
> >>>>>  
> >>>>
> >>>> Are you proposing this as an important (but low risk) bugfix that might
> >>>> qualify for the freeze(s)? If so, please loop in Liming and Mike.
> >>>>
> >>>
> >>> hm... What does freeze mean? 
> >>>
> >>
> >> ah... You mean soft feature freeze for edk2-stable202402. 
> >>
> >> Hi Liming, Michael,
> >>
> >> This change is important but low risk. Could you please consider to add it
> >> to edk2-stable202402 release?
> >>
> >> Thanks a lot!
> >> Joey Lee
> > 
> > This patch is not in edk2-stable202402. Will it to be merged to next 
> > release?
> 
> Thanks for the reminder, and sorry about the delay!
> 
> Merged as commit 2a0d4a2641a7, via
> <https://github.com/tianocore/edk2/pull/5441>.

Thanks for your review and merge!

> 
> For future contributions: please run PatchCheck.py on the patch series
> before formatting and posting it (better yet, submit a personal CI build
> PR).
>

For 'submit personal CI build PR', I was created a pull requests on github:
https://github.com/tianocore/edk2/pull/5349 

Is it the right approach for triggering a CI build PR?

Thanks a lot!
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116478): https://edk2.groups.io/g/devel/message/116478
Mute This Topic: https://groups.io/mt/104153758/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/SmbiosPlatformDxe: tweak fallback release date again

[joeyli via groups.io]

Hi,

On Wed, Feb 07, 2024 at 04:02:52PM +0800, joeyli via groups.io wrote:
> On Wed, Feb 07, 2024 at 03:55:49PM +0800, joeyli wrote:
> > Hi Laszlo,
> > 
> > First, thanks for your review!
> > 
> > On Mon, Feb 05, 2024 at 05:41:25PM +0100, Laszlo Ersek wrote:
> > > On 2/4/24 10:29, Lee, Chun-Yi wrote:
> > > > In case PcdFirmwareReleaseDateString is not set use a valid date
> > > > as fallback. But the default valid date can _NOT_ pass the Microsoft
> > > > SVVP test "Check SMBIOS Table Specific Requirements". The test emitted
> > > > the error message:
> > > > 
> > > > BIOS Release Date string is unexpected length: 8. This string must be in
> > > > MM/DD/ format. No other format is allowed and no additional 
> > > > information
> > > > may be included. See field description in the SMBIOS specification.
> > > > 
> > > > Base on SMBIOS spec v3.7.0:
> > > > 
> > > > 08h 2.0+BIOS Release Date   BYTESTRING
> > > > String number of the BIOS release date. The date
> > > > string, if supplied, is in either mm/dd/yy or
> > > > mm/dd/ format. If the year portion of the string
> > > > is two digits, the year is assumed to be 19yy.
> > > > NOTE: The mm/dd/ format is required for SMBIOS
> > > > version 2.3 and later.
> > > > 
> > > > So, let's tweek the fallback release date again.
> > > > 
> > > > Fixes: a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release 
> > > > date") [edk2-stable202305~327]
> > > > Signed-off-by: "Lee, Chun-Yi" 
> > > > ---
> > > >  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> > > > b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > > > index 0ca3776045..e929da6b81 100644
> > > > --- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > > > +++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > > > @@ -160,7 +160,7 @@ InstallAllStructures (
> > > >  DateStr = (CHAR16 *)FixedPcdGetPtr (PcdFirmwareReleaseDateString);
> > > >  DateLen = StrLen (DateStr);
> > > >  if (DateLen < 3) {
> > > > -  DateStr = L"2/2/2022";
> > > > +  DateStr = L"02/02/2022";
> > > >DateLen = StrLen (DateStr);
> > > >  }
> > > >  
> > > 
> > > Are you proposing this as an important (but low risk) bugfix that might
> > > qualify for the freeze(s)? If so, please loop in Liming and Mike.
> > >
> > 
> > hm... What does freeze mean? 
> >
> 
> ah... You mean soft feature freeze for edk2-stable202402. 
> 
> Hi Liming, Michael,
> 
> This change is important but low risk. Could you please consider to add it
> to edk2-stable202402 release?
> 
> Thanks a lot!
> Joey Lee

This patch is not in edk2-stable202402. Will it to be merged to next release?

Thanks a lot!
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116311): https://edk2.groups.io/g/devel/message/116311
Mute This Topic: https://groups.io/mt/104153758/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] UefiCpuPkg: Get processor extended information for SmmCpuServiceProtocol

[joeyli via groups.io]

Hi Jiaxin, 

Thanks for your reminder! I have tested Gerd's patch and it works to me!

Joey Lee

On Wed, Nov 15, 2023 at 11:30:07AM +, Wu, Jiaxin wrote:
> Hi Joey, 
> 
> Please check your local code whether has the commit 
> 170d4ce8e90abb1eff03852940a69c9d17f8afe5 from Gerd,
> 
> Assert in 1478 means you don't have that patch.
> 
> Besides, I'm also porting the change to BaseXApicLib, see patch: 
> https://edk2.groups.io/g/devel/message/111257
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: joeyli 
> > Sent: Wednesday, November 15, 2023 3:35 PM
> > To: devel@edk2.groups.io; Zhang, Hongbin1 
> > Cc: Dong, Eric ; Ni, Ray ; Kumar,
> > Rahul R ; Gerd Hoffmann ;
> > Zeng, Star ; Wu, Jiaxin 
> > Subject: Re: [edk2-devel] [PATCH v1] UefiCpuPkg: Get processor extended
> > information for SmmCpuServiceProtocol
> > 
> > Hi Hongbin1,
> > 
> > On Mon, May 29, 2023 at 02:39:38PM +0800, Zhang, Hongbin1 via groups.io
> > wrote:
> > > Some features like RAS need to use processor extended information
> > > under smm, So add code to support it
> > >
> > > Signed-off-by: Hongbin1 Zhang 
> > 
> > I got a ASSERT when booting edk2-stable202308 on a issue machine:
> > 
> > ASSERT /home/joeyli/source_code-
> > git/edk2/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c(147
> > 8): (Index != 0) || (LevelType == 0x01)
> > 
> > And, the ASSERT can also be reproduced on edk2 master. After reverted this
> > patch, the ASSERT is gone.
> > 
> > I have filed a bug here:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=4598
> > 
> > I have put some tracing information on bugzilla.
> > 
> > Thank a lot!
> > Joey Lee
> > 
> > > Cc: Eric Dong 
> > > Cc: Ray Ni 
> > > Cc: Rahul Kumar 
> > > Cc: Gerd Hoffmann 
> > > Cc: Star Zeng 
> > > Cc: Jiaxin Wu 
> > > ---
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > index c0e368ea94..8311c3b9de 100644
> > > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > @@ -929,7 +929,7 @@ PiCpuSmmEntry (
> > >  gSmmCpuPrivate->Operation[Index]= SmmCpuNone;
> > >
> > >  if (Index < mNumberOfCpus) {
> > > -  Status = MpServices->GetProcessorInfo (MpServices, Index,
> > >ProcessorInfo[Index]);
> > > +  Status = MpServices->GetProcessorInfo (MpServices, Index |
> > CPU_V2_EXTENDED_TOPOLOGY, >ProcessorInfo[Index]);
> > >ASSERT_EFI_ERROR (Status);
> > >mCpuHotPlugData.ApicId[Index] = gSmmCpuPrivate-
> > >ProcessorInfo[Index].ProcessorId;
> > >
> > > --
> > > 2.37.0.windows.1
> > >
> > >
> > >
> > > 
> > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111269): https://edk2.groups.io/g/devel/message/111269
Mute This Topic: https://groups.io/mt/99209786/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] UefiCpuPkg: Get processor extended information for SmmCpuServiceProtocol

[joeyli via groups.io]

Hi Hongbin1,

On Mon, May 29, 2023 at 02:39:38PM +0800, Zhang, Hongbin1 via groups.io wrote:
> Some features like RAS need to use processor extended information
> under smm, So add code to support it
> 
> Signed-off-by: Hongbin1 Zhang 

I got a ASSERT when booting edk2-stable202308 on a issue machine:

ASSERT 
/home/joeyli/source_code-git/edk2/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c(1478):
 (Index != 0) || (LevelType == 0x01)  

And, the ASSERT can also be reproduced on edk2 master. After reverted this
patch, the ASSERT is gone. 

I have filed a bug here:
https://bugzilla.tianocore.org/show_bug.cgi?id=4598

I have put some tracing information on bugzilla.

Thank a lot!
Joey Lee

> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Star Zeng 
> Cc: Jiaxin Wu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index c0e368ea94..8311c3b9de 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -929,7 +929,7 @@ PiCpuSmmEntry (
>  gSmmCpuPrivate->Operation[Index]= SmmCpuNone;
>  
>  if (Index < mNumberOfCpus) {
> -  Status = MpServices->GetProcessorInfo (MpServices, Index, 
> >ProcessorInfo[Index]);
> +  Status = MpServices->GetProcessorInfo (MpServices, Index | 
> CPU_V2_EXTENDED_TOPOLOGY, >ProcessorInfo[Index]);
>ASSERT_EFI_ERROR (Status);
>mCpuHotPlugData.ApicId[Index] = 
> gSmmCpuPrivate->ProcessorInfo[Index].ProcessorId;
>  
> -- 
> 2.37.0.windows.1
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111242): https://edk2.groups.io/g/devel/message/111242
Mute This Topic: https://groups.io/mt/99209786/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

[joeyli via groups.io]

Hi Min Xu,

On Fri, Apr 07, 2023 at 01:56:05AM +, Min Xu via groups.io wrote:
> On Friday, April 7, 2023 4:29 AM, Tom Lendacky wrote:
> > On 4/5/23 20:42, Xu, Min M wrote:
> > > On April 3, 2023 7:21 PM, Gerd Hoffmann wrote:
> > >>>> I agree that the efi variable store is not secure without smm. But
> > >>>> after 58eb8517ad7b be introduced, the -D SECURE_BOOT_ENABLE
> > doesn't
> > >>>> work with SEV. System just hangs in "NvVarStore FV headers were
> > invalid."
> > >>> Hi, Joeyli
> > >>> ASSERT is triggered in DEBUG version. In RELEASE version ASSERT is
> > >>> skipped
> > >> and an error code is returned. So system will not hang.
> > >>> So another solution is simply remove the ASSERT. Then an error
> > >>> message is
> > >> dumped out and system continues.
> > >>>
> > >>> @Gerd Hoffmann @Tom Lendacky @joeyli What's your thought?
> > >>
> > >> Maybe we just need to call ReserveEmuVariableNvStore a bit later?
> > >>
> > > I think we can still call ReserveEmuVariableNvStore at PEI phase, but
> > > move the initialization of EmuVariableNvStore to
> > >
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/EmuVariableFvbR
> > u
> > > ntimeDxe/Fvb.c#L780-L783 @Tom Lendacky  At this moment, is SEV guest
> > > available to read the content from VarStore?
> > 
> > It's quite possible. If you can work up a quick patch, I'll test it out.
> > 
> Yes, the patch is uploaded here 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4379#c17
>

I have tested new patch. The issue is not produced, but after I applied debug
patch. Looks that the InitializeFvAndVariableStoreForSecureBoot() not be
called. I have put detail log on bugzilla.

Thanks a lot!
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102704): https://edk2.groups.io/g/devel/message/102704
Mute This Topic: https://groups.io/mt/97922617/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

[joeyli via groups.io]

On Mon, Apr 03, 2023 at 12:21:38AM +, Xu, Min M wrote:
> On Friday, March 31, 2023 10:49 PM, Joeyli wrote:
> > On Fri, Mar 31, 2023 at 10:25:09AM +0200, Gerd Hoffmann wrote:
> > > On Fri, Mar 31, 2023 at 03:59:56PM +0800, joeyli wrote:
> > > > Hi Gerd,
> > > >
> > > > On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> > > > > On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > > > > > From: Min M Xu 
> > > > > >
> > > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > > > > >
> > > > > > PlatformInitEmuVariableNvStore is called to initialize the
> > > > > > EmuVariableNvStore with the content pointed by
> > > > > > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is
> > > > > > launched with -bios parameter, UEFI variables will be partially
> > > > > > emulated, and non-volatile variables may lose their contents
> > > > > > after a reboot. This makes the secure boot feature not working.
> > > > > >
> > > > > > But in SEV guest, this design doesn't work. Because at this
> > > > > > point the variable store mapping is still private/encrypted,
> > > > > > OVMF will see ciphertext. So we skip the call of
> > > > > > PlatformInitEmuVariableNvStore in SEV guest.
> > > > >
> > > > > I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> > > > > Without initializing the emu var store you will not get a
> > > > > functional secure boot setup anyway.
> > > >
> > > > In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a
> > > > couple of versions. Removing it will causes problem in VM live 
> > > > migration.
> > >
> > > Hmm?  qemu live-migrates the rom image too.  Only after poweroff and
> > > reboot the guest will see an updated firmware image.
> > >
> > 
> > Thanks for your explanation. Understood.
> > 
> > > > I will prefer Min M's solution, until SEV experts found better
> > > > solution.
> > >
> > > I'd prefer to not poke holes into secure boot.  Re-Initializing the
> > > emu var store from rom on each reset is also needed for security
> > > reasons in case the efi variable store is not in smm-protected flash 
> > > memory.
> > >
> > 
> > I agree that the efi variable store is not secure without smm. But after
> > 58eb8517ad7b be introduced, the -D SECURE_BOOT_ENABLE doesn't work
> > with SEV. System just hangs in "NvVarStore FV headers were invalid."
> Hi, Joeyli
> ASSERT is triggered in DEBUG version. In RELEASE version ASSERT is skipped 
> and an error code is returned. So system will not hang.
> So another solution is simply remove the ASSERT. Then an error message is 
> dumped out and system continues.
>

Ah! You are right. I forgot that I enabled debug mode.
 
> @Gerd Hoffmann @Tom Lendacky @joeyli What's your thought?
>

Removing ASSERT in debug mode can workaround problem. Looks that it just hide a 
problem.

Thanks!
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102677): https://edk2.groups.io/g/devel/message/102677
Mute This Topic: https://groups.io/mt/97922617/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

[joeyli via groups.io]

On Fri, Mar 31, 2023 at 10:25:09AM +0200, Gerd Hoffmann wrote:
> On Fri, Mar 31, 2023 at 03:59:56PM +0800, joeyli wrote:
> > Hi Gerd,
> > 
> > On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> > > On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > > > From: Min M Xu 
> > > > 
> > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > > > 
> > > > PlatformInitEmuVariableNvStore is called to initialize the
> > > > EmuVariableNvStore with the content pointed by
> > > > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is launched
> > > > with -bios parameter, UEFI variables will be partially emulated, and
> > > > non-volatile variables may lose their contents after a reboot. This 
> > > > makes
> > > > the secure boot feature not working.
> > > > 
> > > > But in SEV guest, this design doesn't work. Because at this point the
> > > > variable store mapping is still private/encrypted, OVMF will see
> > > > ciphertext. So we skip the call of PlatformInitEmuVariableNvStore in
> > > > SEV guest.
> > > 
> > > I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> > > Without initializing the emu var store you will not get a functional
> > > secure boot setup anyway.
> > 
> > In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a couple
> > of versions. Removing it will causes problem in VM live migration.
> 
> Hmm?  qemu live-migrates the rom image too.  Only after poweroff and
> reboot the guest will see an updated firmware image.
>

Thanks for your explanation. Understood.
 
> > I will prefer Min M's solution, until SEV experts found better
> > solution.
> 
> I'd prefer to not poke holes into secure boot.  Re-Initializing the emu
> var store from rom on each reset is also needed for security reasons in
> case the efi variable store is not in smm-protected flash memory.
>

I agree that the efi variable store is not secure without smm. But after
58eb8517ad7b be introduced, the -D SECURE_BOOT_ENABLE doesn't work with
SEV. System just hangs in "NvVarStore FV headers were invalid."

If secure boot can not work with SEV (even it is not really secure), why
not just block the building process when SEV with SECURE_BOOT_ENABLE? At
least the issue will not happen at runtime.

Thanks 
Joey Lee



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102316): https://edk2.groups.io/g/devel/message/102316
Mute This Topic: https://groups.io/mt/97922617/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

[joeyli via groups.io]

Hi Gerd,

On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > From: Min M Xu 
> > 
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > 
> > PlatformInitEmuVariableNvStore is called to initialize the
> > EmuVariableNvStore with the content pointed by
> > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is launched
> > with -bios parameter, UEFI variables will be partially emulated, and
> > non-volatile variables may lose their contents after a reboot. This makes
> > the secure boot feature not working.
> > 
> > But in SEV guest, this design doesn't work. Because at this point the
> > variable store mapping is still private/encrypted, OVMF will see
> > ciphertext. So we skip the call of PlatformInitEmuVariableNvStore in
> > SEV guest.
> 
> I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> Without initializing the emu var store you will not get a functional
> secure boot setup anyway.
>

In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a couple
of versions. Removing it will causes problem in VM live migration. I will prefer
Min M's solution, until SEV experts found better solution.

Thank!
Joey Lee 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102247): https://edk2.groups.io/g/devel/message/102247
Mute This Topic: https://groups.io/mt/97922617/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V5 4/8] OvmfPkg/PlatformPei: Update ReserveEmuVariableNvStore

[joeyli via groups.io]

Hi Min M Xu, 

I have filed a EDK2 bug relates to this patch:

Bug 4379 - Got NvVarStore FV headers were invalid when using OVMF with AMD SEV
https://bugzilla.tianocore.org/show_bug.cgi?id=4379  

I got a "NvVarStore FV headers were invalid." assert when using OVMF with AMD
SEV. After reverted this patch, the assert is gone.

Thanks!
Joey Lee

On Tue, Sep 06, 2022 at 12:35:56PM +0800, Min Xu via groups.io wrote:
> From: Min M Xu 
> 
> ReserveEmuVariableNvStore is updated with below 2 functions defined in
> PlatformInitLib:
>  - PlatformReserveEmuVariableNvStore
>  - PlatformInitEmuVariableNvStore
> 
> PlatformInitEmuVariableNvStore works when secure boot feature is enabled.
> This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc)
> and EmuVariableNvStore is cleared when OVMF is launched with -bios
> parameter.
> 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Gerd Hoffmann 
> Acked-by: Gerd Hoffmann 
> Signed-off-by: Min Xu 
> ---
>  OvmfPkg/PlatformPei/Platform.c | 25 +++--
>  1 file changed, 7 insertions(+), 18 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 009db67ee60a..b1f8140d6041 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -220,24 +220,13 @@ ReserveEmuVariableNvStore (
>EFI_PHYSICAL_ADDRESS  VariableStore;
>RETURN_STATUS PcdStatus;
>  
> -  //
> -  // Allocate storage for NV variables early on so it will be
> -  // at a consistent address.  Since VM memory is preserved
> -  // across reboots, this allows the NV variable storage to survive
> -  // a VM reboot.
> -  //
> -  VariableStore =
> -(EFI_PHYSICAL_ADDRESS)(UINTN)
> -AllocateRuntimePages (
> -  EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize))
> -  );
> -  DEBUG ((
> -DEBUG_INFO,
> -"Reserved variable store memory: 0x%lX; size: %dkb\n",
> -VariableStore,
> -(2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
> -));
> -  PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
> +  VariableStore = 
> (EFI_PHYSICAL_ADDRESS)(UINTN)PlatformReserveEmuVariableNvStore ();
> +  PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
> +
> + #ifdef SECURE_BOOT_FEATURE_ENABLED
> +  PlatformInitEmuVariableNvStore ((VOID *)(UINTN)VariableStore);
> + #endif
> +
>ASSERT_RETURN_ERROR (PcdStatus);
>  }
>  
> -- 
> 2.29.2.windows.2
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101482): https://edk2.groups.io/g/devel/message/101482
Mute This Topic: https://groups.io/mt/93494907/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size

[joeyli via groups.io]

Hi Gerd, 

I got a page-fault in CpuIo2Dxe.dll when using edk2-stable202211 ovmf with 
qemu-kvm:

 X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
ExceptionData - 000B  I:0 R:1 U:0 W:1 P:1 PK:0 SS:0 SGX:0
RIP  - 7F2CB5E8, CS  - 0038, RFLAGS - 00010246
RAX  - , RCX - 0001, RDX - 7F2CC5D0
RBX  - 03828014, RSP - 7FF04710, RBP - 7FF04790
RSI  - , RDI - 
R8   - 7FF04938, R9  - 0001, R10 - 0001
R11  - , R12 - 7FF04938, R13 - 0001
R14  - 0001, R15 - 7F2CC3EC
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 80010033, CR2 - 03828014, CR3 - 7FC01000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 7F9DC000 0047, LDTR - 
IDTR - 7F2CD018 0FFF,   TR - 
FXSAVE_STATE - 7FF04370
 Find image based on IP(0x7F2CB5E8) 
/home/joeyli/source_code-git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe/DEBUG/CpuIo2Dxe.dll
 (ImageBase=7F2CA000, EntryPoint=7F2CBDE8) 

After reverted this ecb778d0ac62 patch, the page-fault is gone. And
edk2-stable202311 can also reproduce this CpuIo2Dxe.dll page-fault.

I have filed a edk2 bug against this situation:

Bug 4373 - Got Page-Fault in CpuIo2Dxe.dll when using edk2-stable202211 ovmf 
with qemi-kvm
https://bugzilla.tianocore.org/show_bug.cgi?id=4373

Do you have any idea?

Thanks a lot!
Joey Lee

On Tue, Oct 04, 2022 at 03:47:27PM +0200, Gerd Hoffmann via groups.io wrote:
> In case we have a reliable PhysMemAddressWidth use that to dynamically
> size the 64bit address window.  Allocate 1/8 of the physical address
> space and place the window at the upper end of the address space.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 28 +
>  1 file changed, 28 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index 16ecbfadc30c..ae217d0242ed 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -604,6 +604,33 @@ PlatformAddressWidthFromCpuid (
>}
>  }
>  
> +VOID
> +EFIAPI
> +PlatformDynamicMmioWindow (
> +  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{
> +  UINT64  AddrSpace, MmioSpace;
> +
> +  AddrSpace = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth);
> +  MmioSpace = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth - 3);
> +
> +  if ((PlatformInfoHob->PcdPciMmio64Size < MmioSpace) &&
> +  (PlatformInfoHob->PcdPciMmio64Base + MmioSpace < AddrSpace))
> +  {
> +DEBUG ((DEBUG_INFO, "%a: using dynamic mmio window\n", __func__));
> +DEBUG ((DEBUG_INFO, "%a:   Addr Space 0x%Lx (%Ld GB)\n", __func__, 
> AddrSpace, RShiftU64 (AddrSpace, 30)));
> +DEBUG ((DEBUG_INFO, "%a:   MMIO Space 0x%Lx (%Ld GB)\n", __func__, 
> MmioSpace, RShiftU64 (MmioSpace, 30)));
> +PlatformInfoHob->PcdPciMmio64Size = MmioSpace;
> +PlatformInfoHob->PcdPciMmio64Base = AddrSpace - MmioSpace;
> +  } else {
> +DEBUG ((DEBUG_INFO, "%a: using classic mmio window\n", __func__));
> +  }
> +
> +  DEBUG ((DEBUG_INFO, "%a:   Pci64 Base 0x%Lx\n", __func__, 
> PlatformInfoHob->PcdPciMmio64Base));
> +  DEBUG ((DEBUG_INFO, "%a:   Pci64 Size 0x%Lx\n", __func__, 
> PlatformInfoHob->PcdPciMmio64Size));
> +}
> +
>  /**
>Iterate over the PCI host bridges resources information optionally provided
>in fw-cfg and find the highest address contained in the PCI MMIO windows. 
> If
> @@ -765,6 +792,7 @@ PlatformAddressWidthInitialization (
>if (PlatformInfoHob->PhysMemAddressWidth != 0) {
>  // physical address width is known
>  PlatformInfoHob->FirstNonAddress = FirstNonAddress;
> +PlatformDynamicMmioWindow (PlatformInfoHob);
>  return;
>}
>  
> -- 
> 2.37.3
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101212): https://edk2.groups.io/g/devel/message/101212
Mute This Topic: https://groups.io/mt/94113626/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock

[joeyli via groups.io]

On Tue, Nov 08, 2022 at 02:31:48PM +, Anthony PERARD via groups.io wrote:
> From: Anthony PERARD 
> 
> The PcdFSBClock can be a dynamic PCD. This can be an issue when
> InternalX86GetTimerFrequency() tries to get the value while been
> called with TPL been set to TPL_HIGH_LEVEL.
> 
> When the PCD is dynamic, PcdGet*() calls a function that try to grab a
> lock which set TPL to TPL_NOTIFY. If TPL is already at TPL_HIGH_LEVEL,
> then an assert() in RaiseTPL() fails (in debug build).
> 
> To try to avoid the issue, we'll store the current PcdFSBClock value
> in a local variable the first time we need it.
> 
> The issue was discovered while attempting to boot a Windows guest with
> OvmfXen platform. The issue appear while executing the Windows's boot
> loader EFI application.
> 
> The down side of this change is that when the PCD is FixedAtBuild, the
> value is loaded from a variable rather than been a constant.
> 
> Signed-off-by: Anthony PERARD 

I have tested this patch with edk2-stable202202 and edk2-stable202211. It
works to me to fix problem on bto#4340:

Bug 4340 - Running windows 2k22 on OvmfXen got ASSERT 
/root/source-git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c(66): ((BOOLEAN)(0==1))
https://bugzilla.tianocore.org/show_bug.cgi?id=4340

Thanks a lot!
Joey Lee

> ---
> 
> InternalX86GetTimerFrequency() is called by
> - MicroSecondDelay()
> - NanoSecondDelay()
> - GetPerformanceCounterProperties()
> 
> If one of those functions is called for the first time with a TPL too
> high, the work around in this patch would not work. But it seems to
> workaround the issue in my test case. So maybe that's enough, unless
> someone have a better idea?
> ---
>  MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c 
> b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> index c60589607fde..28ff77ad0c1f 100644
> --- a/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> +++ b/MdePkg/Library/SecPeiDxeTimerLibCpu/X86TimerLib.c
> @@ -90,8 +90,16 @@ InternalX86GetTimerFrequency (
>IN  UINTN  ApicBase
>)
>  {
> +  STATIC UINT32 mFSBClock;
> +
> +  if (mFSBClock == 0) {
> +  //
> +  // Cache current value of PcdFSBClock in case it's a dynamic PCD.
> +  //
> +  mFSBClock = PcdGet32 (PcdFSBClock);
> +  }
>return
> -PcdGet32 (PcdFSBClock) /
> +mFSBClock /
>  mTimerLibLocalApicDivisor[MmioBitFieldRead32 (ApicBase + APIC_TDCR, 0, 
> 3)];
>  }
>  
> -- 
> Anthony PERARD
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99941): https://edk2.groups.io/g/devel/message/99941
Mute This Topic: https://groups.io/mt/94891128/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

Hi Jiewen, 

Thanks for your information. I will follow the process.

Joey Lee

On Wed, Dec 21, 2022 at 08:46:04AM +, Yao, Jiewen wrote:
> Hi Joey
> You are welcome. Thanks to catch the issue and provide the patch.
> 
> One thing to clarify: The patch submitter is expected to pass CI, *before* 
> submit the patch.
> 
> The benefit is that: If the patch passes the review, the maintainer may merge 
> it directly.
> 
> There is no need to trigger another round CI-fix, V2 patch submission and 
> review.
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: joeyli 
> > Sent: Tuesday, December 20, 2022 3:10 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Lee, Chun-Yi ; Xu, Min M
> > ; Gerd Hoffmann ; Tom
> > Lendacky ; James Bottomley
> > ; Aktas, Erdem 
> > Subject: Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: Fix integrity
> > checking failed of NvVarStore in some cases
> > 
> > Hi Jiewen,
> > 
> > Sorry for I didn't create tiano CI on github in time. And thanks for your
> > help to merge my patch.
> > 
> > I will create tiano CI in next time after getting our Review-by tag.
> > 
> > Thanks!
> > Joey Lee
> > 
> > On Sat, Dec 17, 2022 at 03:17:42AM +, Yao, Jiewen via groups.io wrote:
> > > Thanks for the fix.
> > > Reviewed-by: Jiewen Yao 
> > >
> > > Question: Have you run tiano CI by yourself, before submit the patch?
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Lee, Chun-Yi 
> > > > Sent: Thursday, December 15, 2022 10:27 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Xu, Min M ; Gerd Hoffmann
> > > > ; Yao, Jiewen ; Tom
> > Lendacky
> > > > ; James Bottomley ;
> > > > Aktas, Erdem ; Lee, Chun-Yi 
> > > > Subject: [PATCH v2] OvmfPkg/PlatformInitLib: Fix integrity checking 
> > > > failed
> > of
> > > > NvVarStore in some cases
> > > >
> > > > In the commit 4f173db8b4 "OvmfPkg/PlatformInitLib: Add functions for
> > > > EmuVariableNvStore", it introduced a PlatformValidateNvVarStore()
> > function
> > > > for checking the integrity of NvVarStore.
> > > >
> > > > In some cases when the VariableHeader->StartId is VARIABLE_DATA, the
> > > > VariableHeader->State is not just one of the four primary states:
> > > > VAR_IN_DELETED_TRANSITION, VAR_DELETED,
> > VAR_HEADER_VALID_ONLY,
> > > > VAR_ADDED.
> > > > The state may combined two or three states, e.g.
> > > >
> > > > 0x3C = (VAR_IN_DELETED_TRANSITION & VAR_ADDED) &
> > VAR_DELETED
> > > > or
> > > > 0x3D = VAR_ADDED & VAR_DELETED
> > > >
> > > > When the variable store has those variables, system booting/rebooting
> > will
> > > > hangs in a ASSERT:
> > > >
> > > > NvVarStore Variable header State was invalid.
> > > > ASSERT
> > > > /mnt/working/source_code-
> > > > git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > > > ((BOOLEAN)(0==1))
> > > >
> > > > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(),
> > we
> > > > saw some variables which have 0x3C or 0x3D state in store.
> > > > e.g.
> > > >
> > > > UpdateVariable(), VariableName=BootOrder
> > > > L1871, State=003F   <-- VAR_ADDED
> > > > State &= VAR_DELETED=003D
> > > > FlushHobVariableToFlash(), VariableName=BootOrder
> > > > ...
> > > > UpdateVariable(), VariableName=InitialAttemptOrder
> > > > L1977, State=003F
> > > > State &= VAR_IN_DELETED_TRANSITION=003E
> > > > L2376, State=003E
> > > > State &= VAR_DELETED=003C
> > > > FlushHobVariableToFlash(), VariableName=InitialAttemptOrder
> > > > ...
> > > > UpdateVariable(), VariableName=ConIn
> > > > L1977, State=003F
> > > > State &= VAR_IN_DELETED_TRANSITION=003E
> > > > L2376, State=003E
> > > > State &= VAR_DELETED=003C
> > > > FlushHobVariableToFlash(), VariableName=ConIn
> > > > ...
> > > >
> > > > So, only allowing the four primary states is not enough. This patch
> > changes
> > > > the falid states list (Follow Jiewen Yao's suggestio

Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

Hi Jiewen,

Sorry for I didn't create tiano CI on github in time. And thanks for your
help to merge my patch. 

I will create tiano CI in next time after getting our Review-by tag.

Thanks!
Joey Lee

On Sat, Dec 17, 2022 at 03:17:42AM +, Yao, Jiewen via groups.io wrote:
> Thanks for the fix.
> Reviewed-by: Jiewen Yao 
> 
> Question: Have you run tiano CI by yourself, before submit the patch?
> 
> 
> 
> > -Original Message-
> > From: Lee, Chun-Yi 
> > Sent: Thursday, December 15, 2022 10:27 PM
> > To: devel@edk2.groups.io
> > Cc: Xu, Min M ; Gerd Hoffmann
> > ; Yao, Jiewen ; Tom Lendacky
> > ; James Bottomley ;
> > Aktas, Erdem ; Lee, Chun-Yi 
> > Subject: [PATCH v2] OvmfPkg/PlatformInitLib: Fix integrity checking failed 
> > of
> > NvVarStore in some cases
> > 
> > In the commit 4f173db8b4 "OvmfPkg/PlatformInitLib: Add functions for
> > EmuVariableNvStore", it introduced a PlatformValidateNvVarStore() function
> > for checking the integrity of NvVarStore.
> > 
> > In some cases when the VariableHeader->StartId is VARIABLE_DATA, the
> > VariableHeader->State is not just one of the four primary states:
> > VAR_IN_DELETED_TRANSITION, VAR_DELETED, VAR_HEADER_VALID_ONLY,
> > VAR_ADDED.
> > The state may combined two or three states, e.g.
> > 
> > 0x3C = (VAR_IN_DELETED_TRANSITION & VAR_ADDED) & VAR_DELETED
> > or
> > 0x3D = VAR_ADDED & VAR_DELETED
> > 
> > When the variable store has those variables, system booting/rebooting will
> > hangs in a ASSERT:
> > 
> > NvVarStore Variable header State was invalid.
> > ASSERT
> > /mnt/working/source_code-
> > git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > ((BOOLEAN)(0==1))
> > 
> > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
> > saw some variables which have 0x3C or 0x3D state in store.
> > e.g.
> > 
> > UpdateVariable(), VariableName=BootOrder
> > L1871, State=003F   <-- VAR_ADDED
> > State &= VAR_DELETED=003D
> > FlushHobVariableToFlash(), VariableName=BootOrder
> > ...
> > UpdateVariable(), VariableName=InitialAttemptOrder
> > L1977, State=003F
> > State &= VAR_IN_DELETED_TRANSITION=003E
> > L2376, State=003E
> > State &= VAR_DELETED=003C
> > FlushHobVariableToFlash(), VariableName=InitialAttemptOrder
> > ...
> > UpdateVariable(), VariableName=ConIn
> > L1977, State=003F
> > State &= VAR_IN_DELETED_TRANSITION=003E
> > L2376, State=003E
> > State &= VAR_DELETED=003C
> > FlushHobVariableToFlash(), VariableName=ConIn
> > ...
> > 
> > So, only allowing the four primary states is not enough. This patch changes
> > the falid states list (Follow Jiewen Yao's suggestion):
> > 
> > 1. VAR_HEADER_VALID_ONLY (0x7F)
> > - Header added (*)
> > 2. VAR_ADDED (0x3F)
> > - Header + data added
> > 3. VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
> > - marked as deleted, but still valid, before new data is added. (*)
> > 4. VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C)
> > - deleted, after new data is added.
> > 5. VAR_ADDED & VAR_DELETED (0x3D)
> > - deleted directly, without new data.
> > (*) means to support surprise shutdown.
> > 
> > And removed (VAR_IN_DELETED_TRANSITION) and (VAR_DELETED) because
> > they are
> > invalid states.
> > 
> > v2:
> > Follow Jiewen Yao's suggestion to add the following valid states:
> > VAR_ADDED & VAR_DELETED (0x3D)
> > VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
> > VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED
> > (0x3C)
> > and removed the following invalid states:
> > VAR_IN_DELETED_TRANSITION
> > VAR_DELETED
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  OvmfPkg/Library/PlatformInitLib/Platform.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/OvmfPkg/Library/PlatformInitLib/Platform.c
> > b/OvmfPkg/Library/PlatformInitLib/Platform.c
> > index 77f22de046..6963c47e0b 100644
> > --- a/OvmfPkg/Library/PlatformInitLib/Platform.c
> > +++ b/OvmfPkg/Library/PlatformInitLib/Platform.c
> > @@ -702,10 +702,11 @@ PlatformValidateNvVarStore (
> > 
> >VariableOffset = NvVarStoreHeader->Size - sizeof
> > (VARIABLE_STORE_HEADER);
> >  } else {
> > -  if (!((VariableHeader->State == VAR_IN_DELETED_TRANSITION) ||
> > -(VariableHeader->State == VAR_DELETED) ||
> > -(VariableHeader->State == VAR_HEADER_VALID_ONLY) ||
> > -(VariableHeader->State == VAR_ADDED)))
> > +  if (!((VariableHeader->State == VAR_HEADER_VALID_ONLY) ||
> > +   (VariableHeader->State == VAR_ADDED) ||
> > +   (VariableHeader->State == (VAR_ADDED & VAR_DELETED)) ||
> > +   (VariableHeader->State == (VAR_ADDED &
> > VAR_IN_DELETED_TRANSITION)) ||
> > +   (VariableHeader->State == (VAR_ADDED &
> > VAR_IN_DELETED_TRANSITION & VAR_DELETED
> >{
> >  DEBUG ((DEBUG_ERROR, "NvVarStore Variable header State was
> > invalid.\n"));
> >  return FALSE;
> > --
> > 2.35.3
> 
> 
> 
> 
> 

Re: [edk2-devel] [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

On Wed, Dec 14, 2022 at 03:12:22PM +0100, Gerd Hoffmann wrote:
> > Sorry for I forgot to put my testing environment in patch description.
> > My testing is on qemu with OVMF:
> > 
> > - edk2-master or edk2-stable202211
> > build --verbose --debug=1 -D SECURE_BOOT_ENABLE -D TPM_ENABLE -D 
> > TPM_CONFIG_ENABLE \
> > -D NETWORK_IP6_ENABLE -D NETWORK_HTTP_BOOT_ENABLE -a X64 -b DEBUG -t 
> > GCC5 \
> > -p OvmfPkg/OvmfPkgX64.dsc -D FD_SIZE_4MB -D NETWORK_TLS_ENABLE 
> > 
> > - qemu-7.1.0 with libvirt-8.0.0
> >   pc-q35 with pflash type and nvram:
> > hvm
> >  > type='pflash'>/usr/share/qemu/ovmf-x86_64-code.bin
> >  > template='/usr/share/qemu/ovmf-x86_64-vars.bin'>/var/lib/libvirt/qemu/nvram/opensuseTW_VARS.fd
> 
> That is not secure.  You have unprotected writable flash.
> 
> You can either use a build with SMM_REQUIRE=TRUE and run with
> secure='yes', so only the firmware in SMM mode can write to flash.
> 
> Or you run with both code and vars read-only.
> Easiest is OVMF.fd.
>

Thanks for your suggestion! It's really helpful! I will try it.
 
> Or you disable secure boot (SECURE_BOOT_ENABLE=FALSE) in your
> builds.  You still have unprotected writable flash then, but
> it isn't a security hole any more.  And the assert isn't triggered
> either because that code path is only executed for secure boot
> builds.
>

Yes, before I produce the patch, I need to disable SECURE_BOOT_ENABLE
to workaround my VM hang problem.

IMHO, using "variable header State was invalid" assert to prevent user
writes to a unprotected flash is not a good idea. It causes some problem:

- User's existing virtual machine can not boot/reboot after updated to
  edk2-stable202211 OVMF. VM just hangs there and doesn't have any hint.

- The VM still works in the first boot. User doesn't know that second boot
  will hangs because they are writing an unprotected writable flash.

- Even enabled debug log, we don't know what does "NvVarStore Variable header
  State was invalid." mean.

Thanks
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97373): https://edk2.groups.io/g/devel/message/97373
Mute This Topic: https://groups.io/mt/95656983/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

Hi Jiewen, 

Thanks for your response!

On Wed, Dec 14, 2022 at 06:53:42AM +, Yao, Jiewen via groups.io wrote:
> Hey
> Good catch!
> 
> I think we need handle below valid cases:
> 1. VAR_HEADER_VALID_ONLY (0x7F) <-- Header added (*)
> 2. VAR_ADDED (0x3F) <-- Header + data added
> 3. VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E) <-- marked as deleted, but 
> still valid, before new data is added. (*)
> 4. VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C) <-- deleted, 
> after new data is added.
> 5. VAR_ADDED & VAR_DELETED (0x3D) <-- deleted directly, without new data.
> (*) means to support surprise shutdown.
>
> 
> For the patch:
> >if (!((VariableHeader->State == VAR_IN_DELETED_TRANSITION) ||
> >  (VariableHeader->State == VAR_DELETED) ||
> >  (VariableHeader->State == VAR_HEADER_VALID_ONLY) ||
> > -(VariableHeader->State == VAR_ADDED)))
> > +(VariableHeader->State == VAR_ADDED) ||
> > +(VariableHeader->State == (VAR_ADDED & VAR_DELETED)) ||
> > +(VariableHeader->State == (VAR_ADDED & 
> > VAR_IN_DELETED_TRANSITION & VAR_DELETED
> 
> I think:
> A. If we allow (VAR_HEADER_VALID_ONLY), then we support surprise shutdown, we 
> need also allow (VAR_ADDED & VAR_IN_DELETED_TRANSITION). It should be added 
> as well.
> B. The (VAR_IN_DELETED_TRANSITION) and (VAR_DELETED) are invalid state. They 
> should be removed.
>  
> Would you please double check?
>

I have followed your suggestion to change patch to add (VAR_ADDED & 
VAR_IN_DELETED_TRANSITION) and
removed (VAR_IN_DELETED_TRANSITION) and (VAR_DELETED). Like this:

Index: edk2/OvmfPkg/Library/PlatformInitLib/Platform.c
===
--- edk2.orig/OvmfPkg/Library/PlatformInitLib/Platform.c
+++ edk2/OvmfPkg/Library/PlatformInitLib/Platform.c
@@ -704,10 +704,11 @@ PlatformValidateNvVarStore (
   VariableOffset = NvVarStoreHeader->Size - sizeof (VARIABLE_STORE_HEADER);
 } else {
 DEBUG ((DEBUG_ERROR, "VariableHeader->VendorGuid = %g, 
VariableHeader->State = 0x%x\n", VariableHeader->VendorGuid, 
VariableHeader->State));
-  if (!((VariableHeader->State == VAR_IN_DELETED_TRANSITION) ||^M
-(VariableHeader->State == VAR_DELETED) ||^M
-(VariableHeader->State == VAR_HEADER_VALID_ONLY) ||^M
-(VariableHeader->State == VAR_ADDED)))^M
+  if (!((VariableHeader->State == VAR_HEADER_VALID_ONLY) ||^M
+   (VariableHeader->State == VAR_ADDED) ||^M
+   (VariableHeader->State == (VAR_ADDED & VAR_IN_DELETED_TRANSITION)) 
||^M
+   (VariableHeader->State == (VAR_ADDED & VAR_DELETED)) ||^M
+   (VariableHeader->State == (VAR_ADDED & VAR_IN_DELETED_TRANSITION & 
VAR_DELETED^M
   {
 DEBUG ((DEBUG_ERROR, "NvVarStore Variable header State was 
invalid.\n"));
 return FALSE;

The above change works to me no my OVMF.

Thanks a lot!
Joey Lee
 
> 
> 
> 
> > -Original Message-
> > From: Lee, Chun-Yi 
> > Sent: Tuesday, December 13, 2022 11:55 PM
> > To: devel@edk2.groups.io
> > Cc: Xu, Min M ; Gerd Hoffmann
> > ; Yao, Jiewen ; Tom Lendacky
> > ; James Bottomley ;
> > Aktas, Erdem ; Lee, Chun-Yi 
> > Subject: [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of
> > NvVarStore in some cases
> > 
> > In the commit 4f173db8b4 "OvmfPkg/PlatformInitLib: Add functions for
> > EmuVariableNvStore"
> > , it introduced a PlatformValidateNvVarStore() function for checking the
> > integrity of NvVarStore.
> > 
> > In some cases when the VariableHeader->StartId is VARIABLE_DATA, the
> > VariableHeader->State
> > is not just one of the four primary states: VAR_IN_DELETED_TRANSITION,
> > VAR_DELETED,
> > VAR_HEADER_VALID_ONLY, VAR_ADDED. The state may combined two or
> > three
> > states, e.g.
> > 0x3C = (VAR_IN_DELETED_TRANSITION & VAR_ADDED) & VAR_DELETED
> > or
> > 0x3D = VAR_ADDED & VAR_DELETED
> > 
> > When the variable store has those variables, then system booting/rebooting
> > will
> > hangs in a ASSERT:
> > 
> > NvVarStore Variable header State was invalid.
> > ASSERT
> > /mnt/working/source_code-
> > git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > ((BOOLEAN)(0==1))
> > 
> > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
> > can see there have some variables have 0x3C or 0x3D state in store.
> > e.g.
> > 
> > UpdateVariable(), VariableName=BootOrder
> > L1871, State=003F   <-- VAR_ADDED
> > State &= VAR_DELETED=003D
> > FlushHobVariableToFlash(), VariableName=BootOrder
> > ...
> > UpdateVariable(), VariableName=InitialAttemptOrder
> > L1977, State=003F
> > State &= VAR_IN_DELETED_TRANSITION=003E
> > L2376, State=003E
> > State &= VAR_DELETED=003C
> > FlushHobVariableToFlash(), VariableName=InitialAttemptOrder
> > ...
> > UpdateVariable(), VariableName=ConIn
> > L1977, State=003F
> > State &= 

Re: [edk2-devel] [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

Hi,

On Wed, Dec 14, 2022 at 09:46:36PM +0800, joeyli wrote:
> Hi Gerd,
> 
> Thanks for your response! 
> 
> On Wed, Dec 14, 2022 at 07:15:28AM +0100, Gerd Hoffmann via groups.io wrote:
> >   Hi,
> > 
> > > When the variable store has those variables, then system 
> > > booting/rebooting will
> > > hangs in a ASSERT:
> > > 
> > > NvVarStore Variable header State was invalid.
> > > ASSERT
> > > /mnt/working/source_code-git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > > ((BOOLEAN)(0==1))
> > 
> > I'm wondering how you manage to trigger this assert?
> >
> 
> Sorry for I forgot to put my testing environment in patch description.
> My testing is on qemu with OVMF:
> 
> - edk2-master or edk2-stable202211
>   build --verbose --debug=1 -D SECURE_BOOT_ENABLE -D TPM_ENABLE -D 
> TPM_CONFIG_ENABLE \
>   -D NETWORK_IP6_ENABLE -D NETWORK_HTTP_BOOT_ENABLE -a X64 -b DEBUG -t 
> GCC5 \
>   -p OvmfPkg/OvmfPkgX64.dsc -D FD_SIZE_4MB -D NETWORK_TLS_ENABLE 
> 
> - qemu-7.1.0 with libvirt-8.0.0
>   pc-q35 with pflash type and nvram:
> hvm
>  type='pflash'>/usr/share/qemu/ovmf-x86_64-code.bin
>  template='/usr/share/qemu/ovmf-x86_64-vars.bin'>/var/lib/libvirt/qemu/nvram/opensuseTW_VARS.fd
>  
> - grub2 2.06 and Linux kernel 6.1.0-rc5
>

I forgot shim-15.7, the fallback mechanism created new boot entry and
update bootorder in a new *_VARS.fd :

FSOpen: Open '\EFI\opensuse\boot.csv' Success
UpdateVariable() - Boot0003, 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
FlushHobVariableToFlash() - Boot0003, 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
UpdateVariable() - BootOrder, 8BE4DF61-93CA-11D2-AA0D-00E098032B8C 
L1870, State = 0x3F
State &= VAR_DELETED = 0x3D <-- state of BootOrder
FlushHobVariableToFlash() - BootOrder, 8BE4DF61-93CA-11D2-AA0D-00E098032B8C

Joey Lee
 
> Two test cases, both of them can reproduce the assert:
> 
> - First booting to grub2 menu, then "virsh destroy" the guest.
>   The second boot hangs in the "NvVarStore Variable header State was 
> invalid." assert
> 
> - First boot to Linux kernel 6.1.0-rc5, bash shell prompt shows up.
>   Then run shutdown or reboot command.
>   The second boot hangs in in the "NvVarStore Variable header State was 
> invalid." assert 
>  
> > > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
> > > can see there have some variables have 0x3C or 0x3D state in store.
> > > e.g.
> > 
> > PlatformValidateNvVarStore() validates the varstore in ROM before
> > copying it to RAM.  The normal UpdateVariable() cycle changes the
> > copy in RAM ...
> >
> 
> Yes, in the first boot, those variables have 0x3C or 0x3C state be
> created. After shutdown or reboot, system hangs in the second boot.
> The assert shows up in debug log.
> 
> Thanks a lot!
> Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97370): https://edk2.groups.io/g/devel/message/97370
Mute This Topic: https://groups.io/mt/95656983/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/PlatformInitLib: Fix integrity checking failed of NvVarStore in some cases

[joeyli via groups.io]

Hi Gerd,

Thanks for your response! 

On Wed, Dec 14, 2022 at 07:15:28AM +0100, Gerd Hoffmann via groups.io wrote:
>   Hi,
> 
> > When the variable store has those variables, then system booting/rebooting 
> > will
> > hangs in a ASSERT:
> > 
> > NvVarStore Variable header State was invalid.
> > ASSERT
> > /mnt/working/source_code-git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
> > ((BOOLEAN)(0==1))
> 
> I'm wondering how you manage to trigger this assert?
>

Sorry for I forgot to put my testing environment in patch description.
My testing is on qemu with OVMF:

- edk2-master or edk2-stable202211
build --verbose --debug=1 -D SECURE_BOOT_ENABLE -D TPM_ENABLE -D 
TPM_CONFIG_ENABLE \
-D NETWORK_IP6_ENABLE -D NETWORK_HTTP_BOOT_ENABLE -a X64 -b DEBUG -t 
GCC5 \
-p OvmfPkg/OvmfPkgX64.dsc -D FD_SIZE_4MB -D NETWORK_TLS_ENABLE 

- qemu-7.1.0 with libvirt-8.0.0
  pc-q35 with pflash type and nvram:
hvm
/usr/share/qemu/ovmf-x86_64-code.bin
/var/lib/libvirt/qemu/nvram/opensuseTW_VARS.fd
 
- grub2 2.06 and Linux kernel 6.1.0-rc5

Two test cases, both of them can reproduce the assert:

- First booting to grub2 menu, then "virsh destroy" the guest.
  The second boot hangs in the "NvVarStore Variable header State was invalid." 
assert

- First boot to Linux kernel 6.1.0-rc5, bash shell prompt shows up.
  Then run shutdown or reboot command.
  The second boot hangs in in the "NvVarStore Variable header State was 
invalid." assert 
 
> > Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
> > can see there have some variables have 0x3C or 0x3D state in store.
> > e.g.
> 
> PlatformValidateNvVarStore() validates the varstore in ROM before
> copying it to RAM.  The normal UpdateVariable() cycle changes the
> copy in RAM ...
>

Yes, in the first boot, those variables have 0x3C or 0x3C state be
created. After shutdown or reboot, system hangs in the second boot.
The assert shows up in debug log.

Thanks a lot!
Joey Lee


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97367): https://edk2.groups.io/g/devel/message/97367
Mute This Topic: https://groups.io/mt/95656983/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/IncompatiblePciDeviceSupportDxe: Ignore OptionRom in Sev guest

[joeyli via groups.io]

Hi Gerd,

On Fri, Aug 26, 2022 at 07:27:17AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > -  if (TdIsEnabled ()) {
> > +  if (TdIsEnabled () || MemEncryptSevIsEnabled()) {
> 
> I think you can just use CcProbeLib and CcProbe() function to cover both
> tdx and sev.
>

Thanks for your review and suggestion! It works to me.

I will send version 2 patch.

Joey Lee 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92865): https://edk2.groups.io/g/devel/message/92865
Mute This Topic: https://groups.io/mt/93248346/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] ovmf miscompiles with gcc-12

[joeyli via groups.io]

Hi all, 

I have filed this issue on tianocore bugzilla:

Bug 3934 - ovmf miscompiles with gcc-12
https://bugzilla.tianocore.org/show_bug.cgi?id=3934

Thanks
Joey Lee

On Thu, May 19, 2022 at 07:43:12AM +0200, Jiri Slaby via groups.io wrote:
> Hi,
> 
> we discovered that qemu-ovmf-x86_64 doesn't start when compiled using
> gcc-12. Originally reported as:
> https://bugzilla.suse.com/show_bug.cgi?id=1199597
> 
> I run qemu as:
> qemu-kvm -drive file=/dev/null,format=raw -drive
> if=pflash,format=raw,unit=0,readonly=on,file=OVMF.fd -m 3000
> 
> The platform repeatedly resets after TemporaryRamMigration as can be seen in
> the debuglog:
> https://bugzilla.suse.com/attachment.cgi?id=858969
> 
> The reason is TemporaryRamMigration() overwrites rbp unconditionally -- it
> adds an offset to rbp even if rbp is NOT used as a frame pointer
> (-fomit-frame-pointer was always used for compilation here). So commenting
> out:
> > //JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
> 
> makes it all work again. Also marking TemporaryRamMigration() as:
> __attribute__((optimize("-fno-omit-frame-pointer")))
> works around the problem too. (But that doesn't guarantee anything.)
> 
> The code is:
> >   if (SetJump () == 0) {
> >  #if defined (MDE_CPU_IA32)
> > JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
> > JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset;
> >  #endif
> >  #if defined (MDE_CPU_X64)
> > JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset;
> > JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
> >  #endif
> > LongJump (, (UINTN)-1);
> >   }
> 
> It was only coincidence this ever worked -- gcc-11 omits the frame pointer
> too, but apparently the caller (PeiCheckAndSwitchStack) does not use rbp.
> 
> PeiCheckAndSwitchStack() (gcc-12):
> 
> > 79a6:   4c 29 fdsub%r15,%rbp <-- used rbp
> > 79a9:   4d 29 fesub%r15,%r14
> > 79ac:   48 83 ec 20 sub$0x20,%rsp
> > 79b0:   4d 89 e0mov%r12,%r8
> > 79b3:   48 8d 4b 08 lea0x8(%rbx),%rcx
> > 79b7:   48 8b 44 24 50  mov0x50(%rsp),%rax
> > 79bc:   48 8b 54 24 20  mov0x20(%rsp),%rdx
> > 79c1:   4d 29 e8sub%r13,%r8
> > 79c4:   4c 8b 4c 24 30  mov0x30(%rsp),%r9
> > 79c9:   ff 10   call   *(%rax)  <--- call 
> > to TemporaryRamMigration
> > 79cb:   48 83 c4 20 add$0x20,%rsp
> > 79cf:   be 01 00 00 00  mov$0x1,%esi
> > 79d4:   4c 89 f7mov%r14,%rdi
> > 79d7:   e8 f4 a8 ff ff  call   22d0 
> > 79dc:   48 83 ec 20 sub$0x20,%rsp
> > 79e0:   4d 89 f0mov%r14,%r8
> > 79e3:   31 d2   xor%edx,%edx
> > 79e5:   48 89 e9mov%rbp,%rcx   <-- rbp used
> 
> gcc-11 seems to copy rbp to r8 first and operates on r8 there instead.
> 
> Now, what is the right way to fix this? Do the SetJump/LongJump in assembly
> and wrap it into push rbp/pop rbp?
> 
> thanks,
> -- 
> js
> suse labs
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90078): https://edk2.groups.io/g/devel/message/90078
Mute This Topic: https://groups.io/mt/91216215/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] How to create a account on bugzilla.tianocore.org ?

[joeyli via groups.io]

Thanks a  lot!
Joey Lee

On Tue, May 24, 2022 at 03:27:32PM +, Kinney, Michael D wrote:
> The details are on this Wiki page
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of joeyli via 
> > groups.io
> > Sent: Sunday, May 22, 2022 8:23 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] How to create a account on bugzilla.tianocore.org ?
> > 
> > Hi experts,
> > 
> > We want to report bug on bugzilla.tianocore.org but the system doesn't
> > provide link for creating new account. How should I do for creating
> > a account on bugzilla.tianocore.org?
> > 
> > Thanks!
> > Joey Lee
> > 
> > 
> > 
> > 
> > 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90002): https://edk2.groups.io/g/devel/message/90002
Mute This Topic: https://groups.io/mt/91312114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] How to create a account on bugzilla.tianocore.org ?

[joeyli via groups.io]

Hi experts,

We want to report bug on bugzilla.tianocore.org but the system doesn't
provide link for creating new account. How should I do for creating
a account on bugzilla.tianocore.org?

Thanks!
Joey Lee 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89984): https://edk2.groups.io/g/devel/message/89984
Mute This Topic: https://groups.io/mt/91312114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [PATCH 3/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification

[joeyli]

On Tue, Feb 15, 2022 at 08:39:40PM +0100, Michal Suchanek wrote:
> commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> adds support for KEXEC_SIG verification with keys from platform keyring
> but the built-in keys and secondary keyring are not used.
> 
> Add support for the built-in keys and secondary keyring as x86 does.
> 
> Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> Cc: Philipp Rudo 
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek 

Reviewed-by: "Lee, Chun-Yi" 

> ---
>  arch/s390/kernel/machine_kexec_file.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/s390/kernel/machine_kexec_file.c 
> b/arch/s390/kernel/machine_kexec_file.c
> index 8f43575a4dd3..fc6d5f58debe 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long 
> kernel_len)
>   const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
>   struct module_signature *ms;
>   unsigned long sig_len;
> + int ret;
>  
>   /* Skip signature verification when not secure IPLed. */
>   if (!ipl_secure_flag)
> @@ -65,11 +66,18 @@ int s390_verify_sig(const char *kernel, unsigned long 
> kernel_len)
>   return -EBADMSG;
>   }
>  
> - return verify_pkcs7_signature(kernel, kernel_len,
> -   kernel + kernel_len, sig_len,
> -   VERIFY_USE_PLATFORM_KEYRING,
> -   VERIFYING_MODULE_SIGNATURE,
> -   NULL, NULL);
> + ret = verify_pkcs7_signature(kernel, kernel_len,
> +  kernel + kernel_len, sig_len,
> +  VERIFY_USE_SECONDARY_KEYRING,
> +  VERIFYING_MODULE_SIGNATURE,
> +  NULL, NULL);
> + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
> + ret = verify_pkcs7_signature(kernel, kernel_len,
> +  kernel + kernel_len, sig_len,
> +  VERIFY_USE_PLATFORM_KEYRING,
> +  VERIFYING_MODULE_SIGNATURE,
> +  NULL, NULL);
> + return ret;
>  }
>  #endif /* CONFIG_KEXEC_SIG */
>  
> -- 
> 2.31.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/4] kexec, KEYS, arm64: Make use of platform keyring for signature verification

[joeyli]

On Tue, Feb 15, 2022 at 08:39:39PM +0100, Michal Suchanek wrote:
> commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature 
> verify")
> adds platform keyring support on x86 kexec but not arm64.
> 
> Add platform keyring support on arm64 as well.
> 
> Fixes: 278311e417be ("kexec, KEYS: Make use of platform keyring for signature 
> verify")
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek 

Reviewed-by: "Lee, Chun-Yi" 

> ---
>  arch/arm64/kernel/kexec_image.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 1fbf2ee7c005..3dee7b2d8336 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,9 +133,17 @@ static void *image_load(struct kimage *image,
>  #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
>  static int image_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
> - return verify_pefile_signature(kernel, kernel_len,
> -VERIFY_USE_SECONDARY_KEYRING,
> -VERIFYING_KEXEC_PE_SIGNATURE);
> + int ret;
> +
> + ret = verify_pefile_signature(kernel, kernel_len,
> +   VERIFY_USE_SECONDARY_KEYRING,
> +   VERIFYING_KEXEC_PE_SIGNATURE);
> + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
> + ret = verify_pefile_signature(kernel, kernel_len,
> +   VERIFY_USE_PLATFORM_KEYRING,
> +   VERIFYING_KEXEC_PE_SIGNATURE);
> + }
> + return ret;
>  }
>  #endif
>  
> -- 
> 2.31.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot

[joeyli]

On Tue, Feb 15, 2022 at 08:39:38PM +0100, Michal Suchanek wrote:
> commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added 
> to dynamically")
> split of .system_keyring into .builtin_trusted_keys and
> .secondary_trusted_keys broke kexec, thereby preventing kernels signed by
> keys which are now in the secondary keyring from being kexec'd.
> 
> Fix this by passing VERIFY_USE_SECONDARY_KEYRING to
> verify_pefile_signature().
> 
> Cherry-picked from
> commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the 
> secondary keyring to boot")
> 
> Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification 
> support")
> Cc: kexec@lists.infradead.org
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: sta...@kernel.org
> Signed-off-by: Michal Suchanek 

Reviewed-by: "Lee, Chun-Yi" 

> ---
>  arch/arm64/kernel/kexec_image.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 9ec34690e255..1fbf2ee7c005 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
>  #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
>  static int image_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
> - return verify_pefile_signature(kernel, kernel_len, NULL,
> + return verify_pefile_signature(kernel, kernel_len,
> +VERIFY_USE_SECONDARY_KEYRING,
>  VERIFYING_KEXEC_PE_SIGNATURE);
>  }
>  #endif
> -- 
> 2.31.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

[joeyli]

Hi Varad,

Thanks for your review!

On Thu, Apr 15, 2021 at 02:08:32PM +0200, Varad Gautam wrote:
> Hi Joey,
> 
> On 4/9/21 4:46 AM, Lee, Chun-Yi wrote:
> > This patch adds the logic for checking the CodeSigning extended
> > key usage when verifying signature of kernel module or
> > kexec PE binary in PKCS#7.
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  certs/system_keyring.c   |  2 +-
> >  crypto/asymmetric_keys/Kconfig   |  9 +
> >  crypto/asymmetric_keys/pkcs7_trust.c | 37 
> > +---
> >  include/crypto/pkcs7.h   |  3 ++-
> >  4 files changed, 46 insertions(+), 5 deletions(-)
> > 
> > diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> > index 4b693da488f1..c9f8bca0b0d3 100644
> > --- a/certs/system_keyring.c
> > +++ b/certs/system_keyring.c
> > @@ -243,7 +243,7 @@ int verify_pkcs7_message_sig(const void *data, size_t 
> > len,
> > goto error;
> > }
> > }
> > -   ret = pkcs7_validate_trust(pkcs7, trusted_keys);
> > +   ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
> > if (ret < 0) {
> > if (ret == -ENOKEY)
> > pr_devel("PKCS#7 signature not signed with a trusted 
> > key\n");
> > diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> > index 1f1f004dc757..1754812df989 100644
> > --- a/crypto/asymmetric_keys/Kconfig
> > +++ b/crypto/asymmetric_keys/Kconfig
> > @@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
> >   This option provides support for verifying the signature(s) on a
> >   signed PE binary.
> >  
> > +config CHECK_CODESIGN_EKU
> > +   bool "Check codeSigning extended key usage"
> > +   depends on PKCS7_MESSAGE_PARSER=y
> > +   depends on SYSTEM_DATA_VERIFICATION
> > +   help
> > + This option provides support for checking the codeSigning extended
> > + key usage when verifying the signature in PKCS#7. It affects kernel
> > + module verification and kexec PE binary verification.
> > +
> >  endif # ASYMMETRIC_KEY_TYPE
> > diff --git a/crypto/asymmetric_keys/pkcs7_trust.c 
> > b/crypto/asymmetric_keys/pkcs7_trust.c
> > index b531df2013c4..077bfef928b6 100644
> > --- a/crypto/asymmetric_keys/pkcs7_trust.c
> > +++ b/crypto/asymmetric_keys/pkcs7_trust.c
> > @@ -16,12 +16,36 @@
> >  #include 
> >  #include "pkcs7_parser.h"
> >  
> > +#ifdef CONFIG_CHECK_CODESIGN_EKU
> > +static bool check_codesign_eku(struct key *key,
> > +enum key_being_used_for usage)
> > +{
> > +   struct public_key *public_key = key->payload.data[asym_crypto];
> > +
> > +   switch (usage) {
> > +   case VERIFYING_MODULE_SIGNATURE:
> > +   case VERIFYING_KEXEC_PE_SIGNATURE:
> > +   return !!(public_key->eku & EKU_codeSigning);
> > +   default:
> > +   break;
> > +   }
> > +   return true;
> > +}
> > +#else
> > +static bool check_codesign_eku(struct key *key,
> > +enum key_being_used_for usage)
> > +{
> > +   return true;
> > +}
> > +#endif
> > +
> >  /*
> >   * Check the trust on one PKCS#7 SignedInfo block.
> >   */
> >  static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
> > struct pkcs7_signed_info *sinfo,
> > -   struct key *trust_keyring)
> > +   struct key *trust_keyring,
> > +   enum key_being_used_for usage)
> >  {
> > struct public_key_signature *sig = sinfo->sig;
> > struct x509_certificate *x509, *last = NULL, *p;
> > @@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct 
> > pkcs7_message *pkcs7,
> > return -ENOKEY;
> >  
> >  matched:
> > +   if (!check_codesign_eku(key, usage)) {
> 
> Perhaps this can be a generic check_eku_usage() call, with codesigning as one 
> of the
> things it can check for.
>

Because only codesign EKU be checked now. So I prefer to keep it
as my current implementation until there have other EKU requirement. 
 
> > +   pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
> > +   sinfo->index, key_serial(key));
> > +   key_put(key);
> > +   return -ENOKEY;
> > +   }
> > ret = verify_signature(key, sig);
> > key_put(key);
> > if (ret < 0) {
> > @@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct 
> > pkcs7_message *pkcs7,
> >   * May also return -ENOMEM.
> >   */
> >  int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
> > -struct key *trust_keyring)
> > +struct key *trust_keyring,
> > +enum key_being_used_for usage)
> 
> Please also update the comment above to mention the `usage` parameter.
> 
> Regards,
> Varad

I will update it to the comment. Thanks!

Joey Lee

> 
> >  {
> > struct pkcs7_signed_info *sinfo;
> > struct x509_certificate *p;
> > @@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
> >

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

[joeyli]

Hi Varad, 

Thanks for your review!

On Tue, Apr 13, 2021 at 04:28:11PM +0200, Varad Gautam wrote:
> Hi,
> 
> On 3/9/21 10:10 AM, Lee, Chun-Yi wrote:
> > This patch adds the logic for parsing the CodeSign extended key usage
> > extension in X.509. The parsing result will be set to the eku flag
> > which is carried by public key. It can be used in the PKCS#7
> > verification.
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  crypto/asymmetric_keys/x509_cert_parser.c | 24 
> >  include/crypto/public_key.h   |  1 +
> >  include/linux/oid_registry.h  |  5 +
> >  3 files changed, 30 insertions(+)
> > 
> > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
> > b/crypto/asymmetric_keys/x509_cert_parser.c
> > index 52c9b455fc7d..65721313b265 100644
> > --- a/crypto/asymmetric_keys/x509_cert_parser.c
> > +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> > @@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
> > struct x509_parse_context *ctx = context;
> > struct asymmetric_key_id *kid;
> > const unsigned char *v = value;
> > +   int i = 0;
> > +   enum OID oid;
> >  
> > pr_debug("Extension: %u\n", ctx->last_oid);
> >  
> > @@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t 
> > hdrlen,
> > return 0;
> > }
> >  
> > +   if (ctx->last_oid == OID_extKeyUsage) {
> > +   if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
> > +   v[1] != vlen - 2)
> 
> A bad cert might get here with vlen < 2, which would cause indexing into v to 
> break.
> Please add a check for vlen >= 2 before this.
>

I will add the check, thanks for your suggestion!
 
> > +   return -EBADMSG;
> > +   i += 2;
> > +
> > +   while (i < vlen) {
> > +   /* A 10 bytes EKU OID Octet blob =
> > +* ASN1_OID + size byte + 8 bytes OID */
> > +   if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) > 
> > vlen)
> 
> Same here, for i == (vlen - 1), v[i + 1] would fetch outside of v. Or, does 
> the
> ASN.1 layout protect against this?
>

I will move the "(i + 10) > vlen" to the front of "v[i + 1] != 8". It can avoid
that the last octet blob is less than 10 bytes.

Thanks!
Joey Lee
 
> > +   return -EBADMSG;
> > +
> > +   oid = look_up_OID(v + i + 2, v[i + 1]);
> > +   if (oid == OID_codeSigning) {
> > +   ctx->cert->pub->eku |= EKU_codeSigning;
> > +   }
> > +   i += 10;
> > +   }
> > +   pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
> > +   return 0;
> > +   }
> > +
> > return 0;
> >  }
> >  
> > diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> > index 47accec68cb0..1ccaebe2a28b 100644
> > --- a/include/crypto/public_key.h
> > +++ b/include/crypto/public_key.h
> > @@ -28,6 +28,7 @@ struct public_key {
> > bool key_is_private;
> > const char *id_type;
> > const char *pkey_algo;
> > +   unsigned int eku : 9;  /* Extended Key Usage (9-bit) */
> >  };
> >  
> >  extern void public_key_free(struct public_key *key);
> > diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
> > index 4462ed2c18cd..e20e8eb53b21 100644
> > --- a/include/linux/oid_registry.h
> > +++ b/include/linux/oid_registry.h
> > @@ -113,9 +113,14 @@ enum OID {
> > OID_SM2_with_SM3,   /* 1.2.156.10197.1.501 */
> > OID_sm3WithRSAEncryption,   /* 1.2.156.10197.1.504 */
> >  
> > +   /* Extended key purpose OIDs [RFC 5280] */
> > +   OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
> > +
> > OID__NR
> >  };
> >  
> > +#define EKU_codeSigning(1 << 2)
> > +
> >  extern enum OID look_up_OID(const void *data, size_t datasize);
> >  extern int sprint_oid(const void *, size_t, char *, size_t);
> >  extern int sprint_OID(enum OID, char *, size_t);
> > 
> 
> -- 
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5
> 90409 Nürnberg
> Germany
> 
> HRB 36809, AG Nürnberg
> Geschäftsführer: Felix Imendörffer

Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU

[joeyli]

Hi Randy,

On Mon, Feb 22, 2021 at 08:48:42AM -0800, Randy Dunlap wrote:
> Hi,
> 
> On 2/21/21 10:42 PM, Lee, Chun-Yi wrote:
> > Add an openssl command option example for generating CodeSign extended
> > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled.
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  Documentation/admin-guide/module-signing.rst | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/module-signing.rst 
> > b/Documentation/admin-guide/module-signing.rst
> > index 7d7c7c8a545c..b57b30c7125f 100644
> > --- a/Documentation/admin-guide/module-signing.rst
> > +++ b/Documentation/admin-guide/module-signing.rst
> > @@ -170,6 +170,12 @@ generate the public/private key files::
> >-config x509.genkey -outform PEM -out kernel_key.pem \
> >-keyout kernel_key.pem
> >  
> > +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl
> 
>  is enabled,
> 
> > +command option should be added for generating CodeSign extended key usage 
> > in
> 
>   should be added ?
> 
> > +X.509::

Thanks for your review! I will update to next version.

Joey Lee

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

[joeyli]

On Thu, Jan 21, 2021 at 04:32:26PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 21, 2021 at 12:23:53PM +0800, joeyli wrote:
> > Hi Jarkko,
> > 
> > On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chun-Yi wrote:
> > > > This patch adds the logic for parsing the CodeSign extended key usage
> > > > extension in X.509. The parsing result will be set to the eku flag
> > > > which is carried by public key. It can be used in the PKCS#7
> > > > verification.
> > > > 
> > > > Signed-off-by: "Lee, Chun-Yi" 
> > > > ---
> > > >  crypto/asymmetric_keys/x509_cert_parser.c | 24 
> > > >  include/crypto/public_key.h   |  1 +
> > > >  include/linux/oid_registry.h  |  5 +
> > > >  3 files changed, 30 insertions(+)
> > > > 
> > > > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
> > > > b/crypto/asymmetric_keys/x509_cert_parser.c
> > > > index 52c9b455fc7d..65721313b265 100644
> > > > --- a/crypto/asymmetric_keys/x509_cert_parser.c
> > > > +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> > > > @@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t 
> > > > hdrlen,
> > > > struct x509_parse_context *ctx = context;
> > > > struct asymmetric_key_id *kid;
> > > > const unsigned char *v = value;
> > > > +   int i = 0;
> > > > +   enum OID oid;
> > > >  
> > > > pr_debug("Extension: %u\n", ctx->last_oid);
> > > >  
> > > > @@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t 
> > > > hdrlen,
> > > > return 0;
> > > > }
> > > >  
> > > > +   if (ctx->last_oid == OID_extKeyUsage) {
> > > > +   if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | 
> > > > ASN1_SEQ) ||
> > > > +   v[1] != vlen - 2)
> > > > +   return -EBADMSG;
> > > > +   i += 2;
> > > > +
> > > > +   while (i < vlen) {
> > > > +   /* A 10 bytes EKU OID Octet blob =
> > > > +* ASN1_OID + size byte + 8 bytes OID */
> > > > +   if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 
> > > > 10) > vlen)
> > > > +   return -EBADMSG;
> > > > +
> > > > +   oid = look_up_OID(v + i + 2, v[i + 1]);
> > > > +   if (oid == OID_codeSigning) {
> > > > +   ctx->cert->pub->eku |= EKU_codeSigning;
> > > > +   }
> > > > +   i += 10;
> > > > +   }
> > > > +   pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
> > > 
> > > With eBPF around, does this make any sense?
> > >
> > 
> > I think that the dynamic debug log is still easier for checking the EKU
> > setting.
> 
> Why?

There have some certificates may loaded when system boot. In booting stage,
using dynamic debug log for checking EKU is easier than eBPF. 

I am not good on eBPF. Correct me if I missed anything, please!

Thanks a lot!
Joey Lee 

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

[joeyli]

Hi Jarkko,

On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chun-Yi wrote:
> > This patch adds the logic for parsing the CodeSign extended key usage
> > extension in X.509. The parsing result will be set to the eku flag
> > which is carried by public key. It can be used in the PKCS#7
> > verification.
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  crypto/asymmetric_keys/x509_cert_parser.c | 24 
> >  include/crypto/public_key.h   |  1 +
> >  include/linux/oid_registry.h  |  5 +
> >  3 files changed, 30 insertions(+)
> > 
> > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
> > b/crypto/asymmetric_keys/x509_cert_parser.c
> > index 52c9b455fc7d..65721313b265 100644
> > --- a/crypto/asymmetric_keys/x509_cert_parser.c
> > +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> > @@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
> > struct x509_parse_context *ctx = context;
> > struct asymmetric_key_id *kid;
> > const unsigned char *v = value;
> > +   int i = 0;
> > +   enum OID oid;
> >  
> > pr_debug("Extension: %u\n", ctx->last_oid);
> >  
> > @@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t 
> > hdrlen,
> > return 0;
> > }
> >  
> > +   if (ctx->last_oid == OID_extKeyUsage) {
> > +   if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
> > +   v[1] != vlen - 2)
> > +   return -EBADMSG;
> > +   i += 2;
> > +
> > +   while (i < vlen) {
> > +   /* A 10 bytes EKU OID Octet blob =
> > +* ASN1_OID + size byte + 8 bytes OID */
> > +   if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) > 
> > vlen)
> > +   return -EBADMSG;
> > +
> > +   oid = look_up_OID(v + i + 2, v[i + 1]);
> > +   if (oid == OID_codeSigning) {
> > +   ctx->cert->pub->eku |= EKU_codeSigning;
> > +   }
> > +   i += 10;
> > +   }
> > +   pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
> 
> With eBPF around, does this make any sense?
>

I think that the dynamic debug log is still easier for checking the EKU
setting.

Thanks
Joey Lee

Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU

[joeyli]

Hi Randy,

Thanks for your review! I will update it in next version.

Joey Lee

On Wed, Nov 25, 2020 at 09:25:51AM -0800, Randy Dunlap wrote:
> Hi--
> 
> On 11/24/20 11:26 PM, Lee, Chun-Yi wrote:
> > Add an openssl command option example for generating CodeSign extended
> > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU be enabled.
> 
> is enabled.
> 
> > 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  Documentation/admin-guide/module-signing.rst | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/module-signing.rst 
> > b/Documentation/admin-guide/module-signing.rst
> > index f8b584179cff..bc184124d646 100644
> > --- a/Documentation/admin-guide/module-signing.rst
> > +++ b/Documentation/admin-guide/module-signing.rst
> > @@ -170,6 +170,12 @@ generate the public/private key files::
> >-config x509.genkey -outform PEM -out kernel_key.pem \
> >-keyout kernel_key.pem
> >  
> > +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl
> 
>  is enabled,
> 
> > +command option should be added for generating CodeSign extended key usage 
> > in
> > +X.509::
> > +
> > +-addext "extendedKeyUsage=codeSigning"
> > +
> >  The full pathname for the resulting kernel_key.pem file can then be 
> > specified
> >  in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key 
> > therein will
> >  be used instead of an autogenerated keypair.
> > 
> 
> 
> -- 
> ~Randy

Re: [RFC PATCH 2/2] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

[joeyli]

Hi Randy,

On Tue, Oct 20, 2020 at 07:56:29AM -0700, Randy Dunlap wrote:
> On 10/20/20 6:42 AM, Ben Boeckel wrote:
> > On Tue, Oct 20, 2020 at 14:50:01 +0800, Lee, Chun-Yi wrote:
> >> +config CHECK_CODESIGN_EKU
> >> +  bool "Check codeSigning extended key usage"
> >> +  depends on PKCS7_MESSAGE_PARSER=y
> >> +  depends on SYSTEM_DATA_VERIFICATION
> >> +  help
> >> +This option provides support for checking the codeSigning extended
> >> +key usage extension when verifying the signature in PKCS#7. It
> 
> extended ... extension.
> Can we drop one of those or reword it?

I will remove the _extension_ word in next version. Thanks for your review!

Joey Lee

Re: [RFC PATCH 2/2] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

[joeyli]

Hi Ben,

On Tue, Oct 20, 2020 at 09:42:08AM -0400, Ben Boeckel wrote:
> On Tue, Oct 20, 2020 at 14:50:01 +0800, Lee, Chun-Yi wrote:
> > +config CHECK_CODESIGN_EKU
> > +   bool "Check codeSigning extended key usage"
> > +   depends on PKCS7_MESSAGE_PARSER=y
> > +   depends on SYSTEM_DATA_VERIFICATION
> > +   help
> > + This option provides support for checking the codeSigning extended
> > + key usage extension when verifying the signature in PKCS#7. It
> > + affects kernel module verification and kexec PE binary verification
> > + now.
> 
> Is the "now" necessary? Isn't it implied by the option's existence?

Thanks for your review. I will remove the "now" in next version.

Joey Lee

Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction

[joeyli]

Hi Ard,

On Thu, Sep 24, 2020 at 12:47:46PM +0200, Ard Biesheuvel wrote:
> On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi  wrote:
> >
> > This patch moved the logic of creating efivars mount point to the
> > registration of efivars abstraction. It's useful for userland to
> > determine the availability of efivars filesystem by checking the
> > existence of mount point.
> >
> > The 'efivars' platform device be created on generic EFI runtime services
> > platform, so it can be used to determine the availability of efivarfs.
> > But this approach is not available for google gsmi efivars abstraction.
> >
> > This patch be tested on Here on qemu-OVMF and qemu-uboot.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Matthias Brugger 
> > Cc: Fabian Vogt 
> > Cc: Ilias Apalodimas 
> > Cc: Greg Kroah-Hartman 
> > Cc: Arthur Heymans 
> > Cc: Patrick Rudolph 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> 
> I take it this is v3 of [0]? If so, please explain how it deviates
> from v2. If it doesn't deviate from v2, it is better to continue the
> discussion in the other thread.
> 
> For the sake of discussion, it helps to clarify the confusing nomenclature:
> 
> a) 'efivars abstraction' - an internal kernel API that exposes EFI
> variables, and can potentially be backed by an implementation that is
> not EFI based (i.e., Google gsmi)
> 
> b) efivars.ko module, built on top of the efivars abstraction, which
> exposes EFI variables (real ones or gsmi ones) via the deprecated
> sysfs interface
> 
> c) efivarfs filesystem, also built on top of the efivars abstraction,
> which exposes EFI variables (real ones or gsmi ones) via a special
> filesystem independently of sysfs.
> 
> Of course, the sysfs mount point we create for efivarfs is not called
> 'efivarfs' but 'efivars'. The sysfs subdirectory we create for
> efivars.ko is called 'vars'. Sigh.
>

Thanks for your clarification. It's useful to me!
 
> 
> In this patch, you create the mount point for c) based on whether a)
> gets registered (which occurs on systems with EFI Get/SetVariable
> support or GSMI), right? So, to Greg's point, wouldn't it be easier to
> simply check whether efivarfs is listed in /proc/filesystems?
>

Yes, I think that Greg's suggestion is good enough for a userland tool
to detect the availability of efivarfs. You can ignore my patch. 

Thanks for your help!
Joey Lee
 
> It also helps if you could clarify what the actual use case is, rather
> than saying that it is generally useful.
> 
> 
> 
> 
> 
> [0] https://lore.kernel.org/linux-efi/20200825160719.7188-1-j...@suse.com/
> 
> >  drivers/firmware/efi/efi.c  |  7 ---
> >  drivers/firmware/efi/vars.c | 17 +
> >  2 files changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 3aa07c3b5136..23c11a2a3f4d 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void)
> > if (error)
> > goto err_remove_group;
> >
> > -   /* and the standard mountpoint for efivarfs */
> > -   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > -   if (error) {
> > -   pr_err("efivars: Subsystem registration failed.\n");
> > -   goto err_remove_group;
> > -   }
> > -
> > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
> > efi_debugfs_init();
> >
> > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> > index 973eef234b36..6fa7f288d635 100644
> > --- a/drivers/firmware/efi/vars.c
> > +++ b/drivers/firmware/efi/vars.c
> > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars,
> >  const struct efivar_operations *ops,
> >  struct kobject *kobject)
> >  {
> > +   int error;
> > +
> > if (down_interruptible(_lock))
> > return -EINTR;
> >
> > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars,
> >
> > up(_lock);
> >
> > +   /* and the standard mountpoint for efivarfs */
> > +   if (efi_kobj) {
> > +   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > +   if (error) {
> > +   if (down_interruptible(_lock))
> > +   return -EINTR;
> > +   __efivars = NULL;
> > +   up(_lock);
> > +   pr_err("efivars: Subsystem registration failed.\n");
> > +   return error;
> > +   }
> > +   }
> > +
> > return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(efivars_register);
> > @@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars)
> >
> > pr_info("Unregistered efivars operations\n");
> > __efivars = NULL;
> > +   if (efi_kobj)
> > +   sysfs_remove_mount_point(efi_kobj, "efivars");
> >
> > rv = 0;
> >  out:
> > --
> > 2.16.4
> >

Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction

[joeyli]

Hi Greg,

On Thu, Sep 24, 2020 at 11:51:57AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 04:28:33PM +0800, Lee, Chun-Yi wrote:
> > This patch moved the logic of creating efivars mount point to the
> > registration of efivars abstraction. It's useful for userland to
> > determine the availability of efivars filesystem by checking the
> > existence of mount point.
> 
> Why not do what all other tools do, and look in /proc/filesystems?
> 
> Why is efivars "special" in this way?  What tool isn't properly looking
> for the filesystem in that way today?
> 

Thanks for your idea. I think that this is good enough for userland
tool to check the availability of efivarfs. Ignore my patch please.

Regards
Joey Lee

> > The 'efivars' platform device be created on generic EFI runtime services
> > platform, so it can be used to determine the availability of efivarfs.
> > But this approach is not available for google gsmi efivars abstraction.
> 
> I do not understand this last sentence, can you try to explain it
> better?
> 
> > This patch be tested on Here on qemu-OVMF and qemu-uboot.
> 
> How about real hardware?  :)
> 
> > 
> > Cc: Ard Biesheuvel 
> > Cc: Matthias Brugger 
> > Cc: Fabian Vogt 
> > Cc: Ilias Apalodimas 
> > Cc: Greg Kroah-Hartman 
> > Cc: Arthur Heymans 
> > Cc: Patrick Rudolph 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/firmware/efi/efi.c  |  7 ---
> >  drivers/firmware/efi/vars.c | 17 +
> >  2 files changed, 17 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 3aa07c3b5136..23c11a2a3f4d 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void)
> > if (error)
> > goto err_remove_group;
> >  
> > -   /* and the standard mountpoint for efivarfs */
> > -   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > -   if (error) {
> > -   pr_err("efivars: Subsystem registration failed.\n");
> > -   goto err_remove_group;
> > -   }
> > -
> > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
> > efi_debugfs_init();
> >  
> > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> > index 973eef234b36..6fa7f288d635 100644
> > --- a/drivers/firmware/efi/vars.c
> > +++ b/drivers/firmware/efi/vars.c
> > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars,
> >  const struct efivar_operations *ops,
> >  struct kobject *kobject)
> >  {
> > +   int error;
> > +
> > if (down_interruptible(_lock))
> > return -EINTR;
> >  
> > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars,
> >  
> > up(_lock);
> >  
> > +   /* and the standard mountpoint for efivarfs */
> > +   if (efi_kobj) {
> 
> Why test for this?  Can it race?
> 
> thanks,
> 
> greg k-h

Re: [PATCH] platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE

[joeyli]

Hi Timo,

On Tue, Aug 04, 2020 at 02:14:23AM +0200, Timo Witte wrote:
> Got a dmesg message on my AMD Renoir based Acer laptop:
> "acer_wmi: Unknown key number - 0x84" when toggling keyboard
> background light
> 
> Signed-off-by: Timo Witte 

Reviewed-by: "Lee, Chun-Yi" 

Thanks for your help!
Joey Lee

> ---
>  drivers/platform/x86/acer-wmi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 60c18f21588d..87797f785d6a 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -111,6 +111,7 @@ static const struct key_entry acer_wmi_keymap[] 
> __initconst = {
>   {KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} }, /* Display Switch */
>   {KE_IGNORE, 0x81, {KEY_SLEEP} },
>   {KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad Toggle */
> + {KE_IGNORE, 0x84, {KEY_LIGHTS_TOGGLE} }, /* Automatic Keyboard 
> background light toggle */
>   {KE_KEY, KEY_TOUCHPAD_ON, {KEY_TOUCHPAD_ON} },
>   {KE_KEY, KEY_TOUCHPAD_OFF, {KEY_TOUCHPAD_OFF} },
>   {KE_IGNORE, 0x83, {KEY_TOUCHPAD_TOGGLE} },
> -- 
> 2.27.0

Re: [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction

[joeyli]

On Wed, Aug 26, 2020 at 11:56:33PM +0800, Joey Lee wrote:
> Hi Ard,
> 
> On Wed, Aug 26, 2020 at 02:08:18PM +0200, Ard Biesheuvel wrote:
> > On Wed, 26 Aug 2020 at 02:46, Lee, Chun-Yi  wrote:
> > >
> > > This patch creates efivars mount point when active efivars abstraction
> > > be set. It is useful for userland to determine the availability of efivars
> > > filesystem.
> > >
> > > Cc: Matthias Brugger 
> > > Cc: Fabian Vogt 
> > > Cc: Ilias Apalodimas 
> > > Cc: Ard Biesheuvel 
> > > Signed-off-by: "Lee, Chun-Yi" 
> > 
> > Apologies for not bringing this up before: while the patch seems fine,
> > I wonder if we really need this if the purpose is to decide whether
> > efivars is available or not. We already have the 'efivars' platform
> > device for this, and so userland can simply check for the existence of
> > 
> > /sys/devices/platform/efivars.0
> > 
> > and so we don't need to make any changes for this.
> > 
> 
> The platform device only be registered on generic EFI runtime services
> platform. If the efivars abstraction is google gsmi, then userland can
> not use efivars.0 to detectmine the availability of efivars filesystem.
> 
> If we only consider generic EFI platform, then efivars.0 is good enough.
> But if the gsmi implementation joins this game, then my patch should not
> blocks the creation of efivars mount point because gsmi_kobj is not
> initialized yet.
> 
> Maybe the creation of efivars mount point can be moved to
> efivars_register(), after the kobject be set. Then gsmi can also create
> mount point. How do you think?
> 

Here is the patch for my concept. I simply tested on qemu-OVMF and
qemu-uboot.

>From 7c81d3f058a177bb17c4589fe1863b79940f94c3 Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" 
Date: Fri, 28 Aug 2020 00:05:22 +0800
Subject: [PATCH] efi/efivars: Create efivars mount point in the registration
 of efivars abstraction

This patch moved the logic of creating efivars mount point to the registration
of efivars abstraction. It is useful for userland to determine the availability
of efivars filesystem by checking the existence of mount point.

Signed-off-by: Lee, Chun-Yi 
---
 drivers/firmware/efi/efi.c  |  7 ---
 drivers/firmware/efi/vars.c | 17 +
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3aa07c3b5136..23c11a2a3f4d 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -405,13 +405,6 @@ static int __init efisubsys_init(void)
if (error)
goto err_remove_group;
 
-   /* and the standard mountpoint for efivarfs */
-   error = sysfs_create_mount_point(efi_kobj, "efivars");
-   if (error) {
-   pr_err("efivars: Subsystem registration failed.\n");
-   goto err_remove_group;
-   }
-
if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
efi_debugfs_init();
 
diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 973eef234b36..6fa7f288d635 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars,
 const struct efivar_operations *ops,
 struct kobject *kobject)
 {
+   int error;
+
if (down_interruptible(_lock))
return -EINTR;
 
@@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars,
 
up(_lock);
 
+   /* and the standard mountpoint for efivarfs */
+   if (efi_kobj) {
+   error = sysfs_create_mount_point(efi_kobj, "efivars");
+   if (error) {
+   if (down_interruptible(_lock))
+   return -EINTR;
+   __efivars = NULL;
+   up(_lock);
+   pr_err("efivars: Subsystem registration failed.\n");
+   return error;
+   }
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(efivars_register);
@@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars)
 
pr_info("Unregistered efivars operations\n");
__efivars = NULL;
+   if (efi_kobj)
+   sysfs_remove_mount_point(efi_kobj, "efivars");
 
rv = 0;
 out:
-- 
2.16.4

Thanks a lot!
Joey Lee

> On the other hand, the efisubsys_init() does not unregister efivars.0
> platform device in err_unregister block. It causes that efivars and
> efi-pstore be loaded when no generic_ops.
> 
> Let me know if I miss understood any thing, please.
> 
> 
> > 
> > 
> > > ---
> > >
> > > v2:
> > > Using efivars_kobject() helper instead of checking GetVariable or
> > > GetNextVariable EFI runtime services. Because the efivarfs code could be
> > > instantiated using a different efivars abstraction.
> > >
> > >  drivers/firmware/efi/efi.c | 12 +++-
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git 

Re: [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction

[joeyli]

Hi Ard,

On Wed, Aug 26, 2020 at 02:08:18PM +0200, Ard Biesheuvel wrote:
> On Wed, 26 Aug 2020 at 02:46, Lee, Chun-Yi  wrote:
> >
> > This patch creates efivars mount point when active efivars abstraction
> > be set. It is useful for userland to determine the availability of efivars
> > filesystem.
> >
> > Cc: Matthias Brugger 
> > Cc: Fabian Vogt 
> > Cc: Ilias Apalodimas 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: "Lee, Chun-Yi" 
> 
> Apologies for not bringing this up before: while the patch seems fine,
> I wonder if we really need this if the purpose is to decide whether
> efivars is available or not. We already have the 'efivars' platform
> device for this, and so userland can simply check for the existence of
> 
> /sys/devices/platform/efivars.0
> 
> and so we don't need to make any changes for this.
> 

The platform device only be registered on generic EFI runtime services
platform. If the efivars abstraction is google gsmi, then userland can
not use efivars.0 to detectmine the availability of efivars filesystem.

If we only consider generic EFI platform, then efivars.0 is good enough.
But if the gsmi implementation joins this game, then my patch should not
blocks the creation of efivars mount point because gsmi_kobj is not
initialized yet.

Maybe the creation of efivars mount point can be moved to
efivars_register(), after the kobject be set. Then gsmi can also create
mount point. How do you think?

On the other hand, the efisubsys_init() does not unregister efivars.0
platform device in err_unregister block. It causes that efivars and
efi-pstore be loaded when no generic_ops.

Let me know if I miss understood any thing, please.

Thanks a lot!
Joey Lee

> 
> 
> > ---
> >
> > v2:
> > Using efivars_kobject() helper instead of checking GetVariable or
> > GetNextVariable EFI runtime services. Because the efivarfs code could be
> > instantiated using a different efivars abstraction.
> >
> >  drivers/firmware/efi/efi.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 3aa07c3b5136..db483fc68501 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -405,11 +405,13 @@ static int __init efisubsys_init(void)
> > if (error)
> > goto err_remove_group;
> >
> > -   /* and the standard mountpoint for efivarfs */
> > -   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > -   if (error) {
> > -   pr_err("efivars: Subsystem registration failed.\n");
> > -   goto err_remove_group;
> > +   if (efivars_kobject()) {
> > +   /* and the standard mountpoint for efivarfs */
> > +   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > +   if (error) {
> > +   pr_err("efivars: Subsystem registration failed.\n");
> > +   goto err_remove_group;
> > +   }
> > }
> >
> > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
> > --
> > 2.16.4
> >

Re: [PATCH] efi/efivars: create efivars mount point when get variable services are available

[joeyli]

Hi Ard,

On Thu, Aug 20, 2020 at 11:30:27AM +0200, Ard Biesheuvel wrote:
> On Wed, 19 Aug 2020 at 11:28, Lee, Chun-Yi  wrote:
> >
> > The efivars filesystem depends on GetVariable or GetNextVariable EFI
> > runtime services. So the /sys/firmware/efi/efivars does not need to be
> > created when GetVariable and GetNextVariable are not available.
> >
> > It is useful for userland to determine the availability of efivars
> > filesystem.
> >
> > Cc: Ilias Apalodimas 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: "Lee, Chun-Yi" 
> 
> Hello Joey,
> 
> This is not the right check to perform here: the efivarfs code could
> be instantiated using a different efivars abstraction, so whether the
> RT services are implemented is not entirely relevant.
> 
> Please look at commit f88814cc2578c121e6edef686365036db72af0ed
> ("efi/efivars: Expose RT service availability via efivars
> abstraction") for an explanation of the underlying issue, and update
> your patch accordingly.
>

Thanks for youre review! I will look at f88814cc257 and change my
patch for v2.

Joey Lee
 
> 
> > ---
> >  drivers/firmware/efi/efi.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index fdd1db025dbf..929fbf4dfd5d 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -404,11 +404,14 @@ static int __init efisubsys_init(void)
> > if (error)
> > goto err_remove_group;
> >
> > -   /* and the standard mountpoint for efivarfs */
> > -   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > -   if (error) {
> > -   pr_err("efivars: Subsystem registration failed.\n");
> > -   goto err_remove_group;
> > +   if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE |
> > + 
> > EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME)) {
> > +   /* and the standard mountpoint for efivarfs */
> > +   error = sysfs_create_mount_point(efi_kobj, "efivars");
> > +   if (error) {
> > +   pr_err("efivars: Subsystem registration failed.\n");
> > +   goto err_remove_group;
> > +   }
> > }
> >
> > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
> > --
> > 2.16.4
> >

Re: [PATCH V34 10/29] hibernate: Disable when the kernel is locked down

[joeyli]

Hi experts,

On Mon, Jun 24, 2019 at 03:21:23PM +0200, Jiri Kosina wrote:
> On Sat, 22 Jun 2019, Pavel Machek wrote:
> 
> > > There is currently no way to verify the resume image when returning
> > > from hibernate.  This might compromise the signed modules trust model,
> > > so until we can work with signed hibernate images we disable it when the
> > > kernel is locked down.
> > 
> > I keep getting these...
> > 
> > IIRC suse has patches to verify the images.
> 
> Yeah, Joey Lee is taking care of those. CCing.
>

The last time that I sent for hibernation encryption and authentication is
here:
https://lkml.org/lkml/2019/1/3/281

It needs some big changes after review:
 - Simplify the design: remove keyring dependency and trampoline.
 - Encrypted whole snapshot image instead of only data pages.
 - Using TPM:
- Direct use TPM API in hibernation instead of keyring
- Localities (suggested by James Bottomley)

I am still finding enough time to implement those changes, especial TPM
parts.

Thanks
Joey Lee

Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

[joeyli]

On Fri, May 03, 2019 at 04:23:51PM +0200, Ard Biesheuvel wrote:
> On Fri, 3 May 2019 at 10:59, joeyli  wrote:
> >
> > On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 3 May 2019 at 09:18, joeyli  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Thu, May 02, 2019 at 11:04:34AM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi  
> > > > > wrote:
> > > > > >
> > > > > > When loading certificates list from UEFI variable, the original 
> > > > > > error
> > > > > > message direct shows the efi status code from UEFI firmware. It 
> > > > > > looks
> > > > > > ugly:
> > > > > >
> > > > > > [2.335031] Couldn't get size: 0x800e
> > > > > > [2.335032] Couldn't get UEFI MokListRT
> > > > > > [2.339985] Couldn't get size: 0x800e
> > > > > > [2.339987] Couldn't get UEFI dbx list
> > > > > >
> > > > > > So, this patch shows the status string instead of status code.
> > > > > >
> > > > > > On the other hand, the "Couldn't get UEFI" message doesn't need
> > > > > > to be exposed when db/dbx/mok variable do not exist. So, this
> > > > > > patch set the message level to debug.
> > > > > >
> > > > > > v3.
> > > > > > - Print messages similar to db/mok when loading dbx hash to 
> > > > > > blacklist:
> > > > > > [1.500952] EFI: Blacklisting hash of an executable: UEFI:dbx
> > > > > > [1.501773] blacklist: Loaded blacklisting hash
> > > > > > 'bin:80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a'
> > > > > >
> > > > > > - Setting messages for the existence of db/mok/dbx lists to debug 
> > > > > > level.
> > > > > >
> > > > > > v2.
> > > > > > Setting the MODSIGN messages level to debug.
> > > > > >
> > > > > > Link:
> > > > > > https://forums.opensuse.org/showthread.php/535324-MODSIGN-Couldn-t-get-UEFI-db-list?p=2897516#post2897516
> > > > > > Cc: James Morris 
> > > > > > Cc: Serge E. Hallyn" 
> > > > > > Cc: David Howells 
> > > > > > Cc: Nayna Jain 
> > > > > > Cc: Josh Boyer 
> > > > > > Cc: Mimi Zohar 
> > > > > > Signed-off-by: "Lee, Chun-Yi" 
> > > > > > ---
> > > > > >  certs/blacklist.c |  3 +-
> > > > > >  security/integrity/platform_certs/load_uefi.c | 40 
> > > > > > +++
> > > > > >  2 files changed, 31 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/certs/blacklist.c b/certs/blacklist.c
> > > > > > index 3a507b9e2568..f91437e39e44 100644
> > > > > > --- a/certs/blacklist.c
> > > > > > +++ b/certs/blacklist.c
> > > > > > @@ -100,7 +100,8 @@ int mark_hash_blacklisted(const char *hash)
> > > > > > if (IS_ERR(key)) {
> > > > > > pr_err("Problem blacklisting hash (%ld)\n", 
> > > > > > PTR_ERR(key));
> > > > > > return PTR_ERR(key);
> > > > > > -   }
> > > > > > +   } else
> > > > > > +   pr_notice("Loaded blacklisting hash '%s'\n", hash);
> > > > > > return 0;
> > > > > >  }
> > > > > >
> > > > > > diff --git a/security/integrity/platform_certs/load_uefi.c 
> > > > > > b/security/integrity/platform_certs/load_uefi.c
> > > > > > index 81b19c52832b..6b6996e5bc27 100644
> > > > > > --- a/security/integrity/platform_certs/load_uefi.c
> > > > > > +++ b/security/integrity/platform_certs/load_uefi.c
> > > > > > @@ -1,5 +1,7 @@
> > > > > >  // SPDX-License-Identifier: GPL-2.0
> > > > > >
> > > > > > +#define pr_fmt(fmt) "EFI: "fmt
> > > > > > +
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #

Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

[joeyli]

On Fri, May 03, 2019 at 04:23:51PM +0200, Ard Biesheuvel wrote:
> On Fri, 3 May 2019 at 10:59, joeyli  wrote:
> >
> > On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 3 May 2019 at 09:18, joeyli  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Thu, May 02, 2019 at 11:04:34AM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi  
> > > > > wrote:
> > > > > >
> > > > > > When loading certificates list from UEFI variable, the original 
> > > > > > error
> > > > > > message direct shows the efi status code from UEFI firmware. It 
> > > > > > looks
> > > > > > ugly:
> > > > > >
> > > > > > [2.335031] Couldn't get size: 0x800e
> > > > > > [2.335032] Couldn't get UEFI MokListRT
> > > > > > [2.339985] Couldn't get size: 0x800e
> > > > > > [2.339987] Couldn't get UEFI dbx list
> > > > > >
> > > > > > So, this patch shows the status string instead of status code.
> > > > > >
> > > > > > On the other hand, the "Couldn't get UEFI" message doesn't need
> > > > > > to be exposed when db/dbx/mok variable do not exist. So, this
> > > > > > patch set the message level to debug.
> > > > > >
> > > > > > v3.
> > > > > > - Print messages similar to db/mok when loading dbx hash to 
> > > > > > blacklist:
> > > > > > [1.500952] EFI: Blacklisting hash of an executable: UEFI:dbx
> > > > > > [1.501773] blacklist: Loaded blacklisting hash
> > > > > > 'bin:80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a'
> > > > > >
> > > > > > - Setting messages for the existence of db/mok/dbx lists to debug 
> > > > > > level.
> > > > > >
> > > > > > v2.
> > > > > > Setting the MODSIGN messages level to debug.
> > > > > >
> > > > > > Link:
> > > > > > https://forums.opensuse.org/showthread.php/535324-MODSIGN-Couldn-t-get-UEFI-db-list?p=2897516#post2897516
> > > > > > Cc: James Morris 
> > > > > > Cc: Serge E. Hallyn" 
> > > > > > Cc: David Howells 
> > > > > > Cc: Nayna Jain 
> > > > > > Cc: Josh Boyer 
> > > > > > Cc: Mimi Zohar 
> > > > > > Signed-off-by: "Lee, Chun-Yi" 
> > > > > > ---
> > > > > >  certs/blacklist.c |  3 +-
> > > > > >  security/integrity/platform_certs/load_uefi.c | 40 
> > > > > > +++
> > > > > >  2 files changed, 31 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/certs/blacklist.c b/certs/blacklist.c
> > > > > > index 3a507b9e2568..f91437e39e44 100644
> > > > > > --- a/certs/blacklist.c
> > > > > > +++ b/certs/blacklist.c
> > > > > > @@ -100,7 +100,8 @@ int mark_hash_blacklisted(const char *hash)
> > > > > > if (IS_ERR(key)) {
> > > > > > pr_err("Problem blacklisting hash (%ld)\n", 
> > > > > > PTR_ERR(key));
> > > > > > return PTR_ERR(key);
> > > > > > -   }
> > > > > > +   } else
> > > > > > +   pr_notice("Loaded blacklisting hash '%s'\n", hash);
> > > > > > return 0;
> > > > > >  }
> > > > > >
> > > > > > diff --git a/security/integrity/platform_certs/load_uefi.c 
> > > > > > b/security/integrity/platform_certs/load_uefi.c
> > > > > > index 81b19c52832b..6b6996e5bc27 100644
> > > > > > --- a/security/integrity/platform_certs/load_uefi.c
> > > > > > +++ b/security/integrity/platform_certs/load_uefi.c
> > > > > > @@ -1,5 +1,7 @@
> > > > > >  // SPDX-License-Identifier: GPL-2.0
> > > > > >
> > > > > > +#define pr_fmt(fmt) "EFI: "fmt
> > > > > > +
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #

Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

[joeyli]

On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote:
> On Fri, 3 May 2019 at 09:18, joeyli  wrote:
> >
> > Hi Ard,
> >
> > On Thu, May 02, 2019 at 11:04:34AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi  wrote:
> > > >
> > > > When loading certificates list from UEFI variable, the original error
> > > > message direct shows the efi status code from UEFI firmware. It looks
> > > > ugly:
> > > >
> > > > [2.335031] Couldn't get size: 0x800e
> > > > [2.335032] Couldn't get UEFI MokListRT
> > > > [2.339985] Couldn't get size: 0x800e
> > > > [2.339987] Couldn't get UEFI dbx list
> > > >
> > > > So, this patch shows the status string instead of status code.
> > > >
> > > > On the other hand, the "Couldn't get UEFI" message doesn't need
> > > > to be exposed when db/dbx/mok variable do not exist. So, this
> > > > patch set the message level to debug.
> > > >
> > > > v3.
> > > > - Print messages similar to db/mok when loading dbx hash to blacklist:
> > > > [1.500952] EFI: Blacklisting hash of an executable: UEFI:dbx
> > > > [1.501773] blacklist: Loaded blacklisting hash
> > > > 'bin:80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a'
> > > >
> > > > - Setting messages for the existence of db/mok/dbx lists to debug level.
> > > >
> > > > v2.
> > > > Setting the MODSIGN messages level to debug.
> > > >
> > > > Link:
> > > > https://forums.opensuse.org/showthread.php/535324-MODSIGN-Couldn-t-get-UEFI-db-list?p=2897516#post2897516
> > > > Cc: James Morris 
> > > > Cc: Serge E. Hallyn" 
> > > > Cc: David Howells 
> > > > Cc: Nayna Jain 
> > > > Cc: Josh Boyer 
> > > > Cc: Mimi Zohar 
> > > > Signed-off-by: "Lee, Chun-Yi" 
> > > > ---
> > > >  certs/blacklist.c |  3 +-
> > > >  security/integrity/platform_certs/load_uefi.c | 40 
> > > > +++
> > > >  2 files changed, 31 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/certs/blacklist.c b/certs/blacklist.c
> > > > index 3a507b9e2568..f91437e39e44 100644
> > > > --- a/certs/blacklist.c
> > > > +++ b/certs/blacklist.c
> > > > @@ -100,7 +100,8 @@ int mark_hash_blacklisted(const char *hash)
> > > > if (IS_ERR(key)) {
> > > > pr_err("Problem blacklisting hash (%ld)\n", 
> > > > PTR_ERR(key));
> > > > return PTR_ERR(key);
> > > > -   }
> > > > +   } else
> > > > +   pr_notice("Loaded blacklisting hash '%s'\n", hash);
> > > > return 0;
> > > >  }
> > > >
> > > > diff --git a/security/integrity/platform_certs/load_uefi.c 
> > > > b/security/integrity/platform_certs/load_uefi.c
> > > > index 81b19c52832b..6b6996e5bc27 100644
> > > > --- a/security/integrity/platform_certs/load_uefi.c
> > > > +++ b/security/integrity/platform_certs/load_uefi.c
> > > > @@ -1,5 +1,7 @@
> > > >  // SPDX-License-Identifier: GPL-2.0
> > > >
> > > > +#define pr_fmt(fmt) "EFI: "fmt
> > > > +
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -35,6 +37,18 @@ static __init bool uefi_check_ignore_db(void)
> > > > return status == EFI_SUCCESS;
> > > >  }
> > > >
> > > > +static void str16_to_str(efi_char16_t *str16, char *str, int str_size)
> > > > +{
> > > > +   int i = 0;
> > > > +
> > > > +   while (str16[i] != '\0' && i < (str_size - 1)) {
> > > > +   str[i] = str16[i];
> > > > +   i++;
> > > > +   }
> > > > +
> > > > +   str[i] = '\0';
> > > > +}
> > > > +
> > > >  /*
> > > >   * Get a certificate list blob from the named EFI variable.
> > > >   */
> > > > @@ -44,13 +58,20 @@ static __init void *get_cert_list(efi_char16_t 
> > > > *name, efi_guid_t *guid,
> > > > efi_status_t status;
> > > > unsigne

Re: [PATCH 1/2 v2] efi: add a function to convert the status value to string

[joeyli]

On Fri, May 03, 2019 at 08:16:42AM +0200, Ard Biesheuvel wrote:
> On Fri, 3 May 2019 at 08:15, joeyli  wrote:
> >
> > On Thu, May 02, 2019 at 10:53:31AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi  wrote:
> > > >
> > > > This function can be used to convert EFI status value to string
> > > > for printing out debug message. Using this function can improve
> > > > the readability of log.
> > > >
> > > > v2.
> > >
> > > Please move the changelog out of the commit log (move it below the ---
> > > further down)
> > >
> >
> > OK! I will moved the changelog out of the commit log.
> >
> > > > - Changed the wording in subject and description.
> > > > - Moved the marco immediately after the status value definitions.
> > > > - Turned into a proper function instead of inline.
> > > >
> > >
> > > You missed my point here. A proper function means the function in a .c
> > > file, and only the declaration in a .h file. This way, you are still
> > > duplicating the literal strings into every object file that references
> > > this function.
> > >
> >
> > Sorry for I missunderstood. I will move the function to load_uefi.c.
> >
> 
> No, please move it to a file that is shared between all EFI code.

I see! I will move the function to the position that it is just behind
efi_status_to_str() in drivers/firmware/efi/efi.c. Please let me know
if the position is not suitable.

Thanks a lot!
Joey Lee

Re: [PATCH 1/2 v2] efi: add a function to convert the status value to string

[joeyli]

On Thu, May 02, 2019 at 10:53:31AM +0200, Ard Biesheuvel wrote:
> On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi  wrote:
> >
> > This function can be used to convert EFI status value to string
> > for printing out debug message. Using this function can improve
> > the readability of log.
> >
> > v2.
> 
> Please move the changelog out of the commit log (move it below the ---
> further down)
>

OK! I will moved the changelog out of the commit log.
 
> > - Changed the wording in subject and description.
> > - Moved the marco immediately after the status value definitions.
> > - Turned into a proper function instead of inline.
> >
> 
> You missed my point here. A proper function means the function in a .c
> file, and only the declaration in a .h file. This way, you are still
> duplicating the literal strings into every object file that references
> this function.
>

Sorry for I missunderstood. I will move the function to load_uefi.c.

Thanks a lot!
Joey Lee

Re: [PATCH 1/2] efi: add a function for transferring status to string

[joeyli]

Hi Mimi,

On Wed, Mar 27, 2019 at 03:04:02PM -0400, Mimi Zohar wrote:
> On Wed, 2019-03-27 at 19:58 +0100, Ard Biesheuvel wrote:
> > On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi  wrote:
> > >
> > > This function can be used to transfer EFI status code to string
> > > for printing out debug message. Using this function can improve
> > > the readability of log.
> 
> Maybe instead of "for transferring status" use "to convert the status
> value to a" in the Subject line and here in the patch description.
>

Thanks for your suggestion. I will change subject and description.
 
> > >
> > > Cc: Ard Biesheuvel 
> > > Cc: Kees Cook 
> > > Cc: Anton Vorontsov 
> > > Cc: Colin Cross 
> > > Cc: Tony Luck 
> > > Signed-off-by: "Lee, Chun-Yi" 
> > > ---
> > >  include/linux/efi.h | 28 
> > >  1 file changed, 28 insertions(+)
> > >
> > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > index 54357a258b35..a43cb0dc37af 100644
> > > --- a/include/linux/efi.h
> > > +++ b/include/linux/efi.h
> > > @@ -1768,4 +1768,32 @@ struct linux_efi_memreserve {
> > >  #define EFI_MEMRESERVE_COUNT(size) (((size) - sizeof(struct 
> > > linux_efi_memreserve)) \
> > > / sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> > >
> > > +#define EFI_STATUS_STR(_status) \
> > > +case EFI_##_status: \
> > > +   return "EFI_" __stringify(_status);
> > > +
> > > +static inline char *
> > > +efi_status_to_str(efi_status_t status)
> > > +{
> > > +   switch (status) {
> > > +   EFI_STATUS_STR(SUCCESS)
> > > +   EFI_STATUS_STR(LOAD_ERROR)
> > > +   EFI_STATUS_STR(INVALID_PARAMETER)
> > > +   EFI_STATUS_STR(UNSUPPORTED)
> > > +   EFI_STATUS_STR(BAD_BUFFER_SIZE)
> > > +   EFI_STATUS_STR(BUFFER_TOO_SMALL)
> > > +   EFI_STATUS_STR(NOT_READY)
> > > +   EFI_STATUS_STR(DEVICE_ERROR)
> > > +   EFI_STATUS_STR(WRITE_PROTECTED)
> > > +   EFI_STATUS_STR(OUT_OF_RESOURCES)
> > > +   EFI_STATUS_STR(NOT_FOUND)
> > > +   EFI_STATUS_STR(ABORTED)
> > > +   EFI_STATUS_STR(SECURITY_VIOLATION)
> > > +   default:
> > > +   pr_warn("Unknown efi status: 0x%lx", status);
> > > +   }
> > > +
> > > +   return "Unknown efi status";
> > > +}
> > > +
> > >  #endif /* _LINUX_EFI_H */
> > > --
> > > 2.16.4
> > >
> > 
> > Please turn this into a proper function so that not every calling
> > object has to duplicate all these strings.
> 
> Hi Ard,
> 
> Keeping the status values and strings in sync is difficult.  I was
> going to suggest moving the macro immediately after the status value
> definitions.
>

I will move the code to after the status value definitions.

Thanks
Joey Lee 

Re: [PATCH 1/2] efi: add a function for transferring status to string

[joeyli]

Hi Ard,

On Wed, Mar 27, 2019 at 07:58:03PM +0100, Ard Biesheuvel wrote:
> On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi  wrote:
> >
> > This function can be used to transfer EFI status code to string
> > for printing out debug message. Using this function can improve
> > the readability of log.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Kees Cook 
> > Cc: Anton Vorontsov 
> > Cc: Colin Cross 
> > Cc: Tony Luck 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  include/linux/efi.h | 28 
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 54357a258b35..a43cb0dc37af 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -1768,4 +1768,32 @@ struct linux_efi_memreserve {
> >  #define EFI_MEMRESERVE_COUNT(size) (((size) - sizeof(struct 
> > linux_efi_memreserve)) \
> > / sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> >
> > +#define EFI_STATUS_STR(_status) \
> > +case EFI_##_status: \
> > +   return "EFI_" __stringify(_status);
> > +
> > +static inline char *
> > +efi_status_to_str(efi_status_t status)
> > +{
> > +   switch (status) {
> > +   EFI_STATUS_STR(SUCCESS)
> > +   EFI_STATUS_STR(LOAD_ERROR)
> > +   EFI_STATUS_STR(INVALID_PARAMETER)
> > +   EFI_STATUS_STR(UNSUPPORTED)
> > +   EFI_STATUS_STR(BAD_BUFFER_SIZE)
> > +   EFI_STATUS_STR(BUFFER_TOO_SMALL)
> > +   EFI_STATUS_STR(NOT_READY)
> > +   EFI_STATUS_STR(DEVICE_ERROR)
> > +   EFI_STATUS_STR(WRITE_PROTECTED)
> > +   EFI_STATUS_STR(OUT_OF_RESOURCES)
> > +   EFI_STATUS_STR(NOT_FOUND)
> > +   EFI_STATUS_STR(ABORTED)
> > +   EFI_STATUS_STR(SECURITY_VIOLATION)
> > +   default:
> > +   pr_warn("Unknown efi status: 0x%lx", status);
> > +   }
> > +
> > +   return "Unknown efi status";
> > +}
> > +
> >  #endif /* _LINUX_EFI_H */
> > --
> > 2.16.4
> >
> 
> Please turn this into a proper function so that not every calling
> object has to duplicate all these strings.

OK! I will move them to function.

Thanks for your review!
Joey Lee

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

On Wed, Jan 09, 2019 at 05:47:53PM +0100, Stephan Mueller wrote:
> Am Mittwoch, 9. Januar 2019, 17:39:58 CET schrieb joeyli:
> 
> Hi joeyli,
> 
> > 
> > I am doing encrypt-then-MAC.
> 
> Note, this is what the authenc() AEAD cipher does.
>

OK.. Thanks for your reminding. I will look at it.

Joey Lee 

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

On Thu, Jan 10, 2019 at 05:09:46PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 10, 2019 at 7:13 AM joeyli  wrote:
> >
> > On Wed, Jan 09, 2019 at 10:47:42AM -0800, Andy Lutomirski wrote:
> > > On Wed, Jan 9, 2019 at 8:40 AM joeyli  wrote:
> > > >
> > > > Hi Andy,
> > > >
> > > > Thanks for your review!
> > > >
> > > > On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote:
> > > > > > On Jan 7, 2019, at 9:37 AM, joeyli  wrote:
> > > > > >
> > > > > > Hi Pavel,
> > > > > >
> > > > > > Thanks for your review!
> > > > > >
> > > > > >> On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote:
> > > > > >> Hi!
> > > > > >>
> > > > > >>> This patchset is the implementation of encryption and 
> > > > > >>> authentication
> > > > > >>> for hibernate snapshot image. The image will be encrypted by AES 
> > > > > >>> and
> > > > > >>> authenticated by HMAC.
> > > > > >>
> > > > > >> Ok, so you encrypt.
> > > > > >
> > > > > > Yes, encryption and authentication.
> > > > > >
> > > > > >>> The hibernate function can be used to snapshot memory pages to an 
> > > > > >>> image,
> > > > > >>> then kernel restores the image to memory space in a appropriate 
> > > > > >>> time.
> > > > > >>> There have secrets in snapshot image and cracker may modifies it 
> > > > > >>> for
> > > > > >>> hacking system. Encryption and authentication of snapshot image 
> > > > > >>> can protect
> > > > > >>> the system.
> > > > > >>>
> > > > > >>> Hibernate function requests the master key through key retention 
> > > > > >>> service.
> > > > > >>> The snapshot master key can be a trusted key or a user defined 
> > > > > >>> key. The
> > > > > >>> name of snapshot master key is fixed to "swsusp-kmk". User should 
> > > > > >>> loads
> > > > > >>> swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> > > > > >>> e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> > > > > >>
> > > > > >> But if userspace has a key, encryption is useless against root.
> > > > > >
> > > > > > Yes, but this concern is not only for hibernation encryption. This 
> > > > > > patch
> > > > > > set does not provide solution against this concern.
> > > > > >
> > > > > > The purpose of this patch set is to encrypt and authenticate 
> > > > > > hibernate
> > > > > > snapshot image in kernel space. It also requests key through keyring
> > > > > > mechanism. Which means that we can easy to adapt to new key type 
> > > > > > from
> > > > > > keyring in the future.
> > > > > >
> > > > > > Currently TPM trusted key or user defined key types are not against
> > > > > > root. Even using the TPM trusted key, it still can be unsealed by 
> > > > > > root
> > > > > > before the PCRs be capped (unless we capped PCRs in kernel).
> > > > > >
> > > > > > My solution for keeping the secret by kernel is the EFI secure key 
> > > > > > type:
> > > > > >https://lkml.org/lkml/2018/8/5/31
> > > > > >
> > > > > > But the EFI boot variable doesn't design for keeping secret, so 
> > > > > > Windows
> > > > > > and OEM/ODM do not use boot variable to keep secret. So this idea 
> > > > > > can
> > > > > > not be accepted. We must think other key type against root.
> > > > > >
> > > > > >>> The TPM trusted key type is preferred to be the master key. But 
> > > > > >>> user
> > > > > >>> defined key can also be used for testing or when the platform 
> > > > > >>> doesn't
> > > > > >>> have TPM. User mus

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

On Wed, Jan 09, 2019 at 10:47:42AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 9, 2019 at 8:40 AM joeyli  wrote:
> >
> > Hi Andy,
> >
> > Thanks for your review!
> >
> > On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote:
> > > > On Jan 7, 2019, at 9:37 AM, joeyli  wrote:
> > > >
> > > > Hi Pavel,
> > > >
> > > > Thanks for your review!
> > > >
> > > >> On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote:
> > > >> Hi!
> > > >>
> > > >>> This patchset is the implementation of encryption and authentication
> > > >>> for hibernate snapshot image. The image will be encrypted by AES and
> > > >>> authenticated by HMAC.
> > > >>
> > > >> Ok, so you encrypt.
> > > >
> > > > Yes, encryption and authentication.
> > > >
> > > >>> The hibernate function can be used to snapshot memory pages to an 
> > > >>> image,
> > > >>> then kernel restores the image to memory space in a appropriate time.
> > > >>> There have secrets in snapshot image and cracker may modifies it for
> > > >>> hacking system. Encryption and authentication of snapshot image can 
> > > >>> protect
> > > >>> the system.
> > > >>>
> > > >>> Hibernate function requests the master key through key retention 
> > > >>> service.
> > > >>> The snapshot master key can be a trusted key or a user defined key. 
> > > >>> The
> > > >>> name of snapshot master key is fixed to "swsusp-kmk". User should 
> > > >>> loads
> > > >>> swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> > > >>> e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> > > >>
> > > >> But if userspace has a key, encryption is useless against root.
> > > >
> > > > Yes, but this concern is not only for hibernation encryption. This patch
> > > > set does not provide solution against this concern.
> > > >
> > > > The purpose of this patch set is to encrypt and authenticate hibernate
> > > > snapshot image in kernel space. It also requests key through keyring
> > > > mechanism. Which means that we can easy to adapt to new key type from
> > > > keyring in the future.
> > > >
> > > > Currently TPM trusted key or user defined key types are not against
> > > > root. Even using the TPM trusted key, it still can be unsealed by root
> > > > before the PCRs be capped (unless we capped PCRs in kernel).
> > > >
> > > > My solution for keeping the secret by kernel is the EFI secure key type:
> > > >https://lkml.org/lkml/2018/8/5/31
> > > >
> > > > But the EFI boot variable doesn't design for keeping secret, so Windows
> > > > and OEM/ODM do not use boot variable to keep secret. So this idea can
> > > > not be accepted. We must think other key type against root.
> > > >
> > > >>> The TPM trusted key type is preferred to be the master key. But user
> > > >>> defined key can also be used for testing or when the platform doesn't
> > > >>> have TPM. User must be aware that the security of user key relies on
> > > >>> user space. If the root account be compromised, then the user key will
> > > >>> easy to be grabbed.
> > > >>
> > > >> In the TPM case, does userland have access to the key?
> > > >
> > > > In the TPM case, userland can only touch the sealed key blob. So 
> > > > userland
> > > > doesn't know the real secret. But it has risk that root unseals the key
> > > > before PCRs be capped.
> > > >
> > > >> Please explain your security goals.
> > > >
> > > > My security goals:
> > > >
> > > > - Encrypt and authicate hibernate snapshot image in kernel space. 
> > > > Userspace
> > > >  can only touch an encrypted and signed snapshot image.
> > >
> > > Signed?
> > >
> > > I’m not entirely convinced that the keyring mechanism is what you
> > > want. ISTM that there are two goals here:
> > >
> > > a) Encryption: it should be as hard as can reasonably be arranged to
> > > extract sec

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi James

On Tue, Jan 08, 2019 at 10:49:39PM -0800, James Bottomley wrote:
> On Tue, 2019-01-08 at 17:43 -0800, Andy Lutomirski wrote:
> > [Adding Jarkko because this stuff relates to the TPM.]
> > 
> > On Tue, Jan 8, 2019 at 4:44 PM James Bottomley
> >  wrote:
> > > 
> > > On Tue, 2019-01-08 at 15:54 -0800, Andy Lutomirski wrote:
> > > > > On Jan 7, 2019, at 11:09 PM, Stephan Mueller  > > > > de>
> > > > > wrote:
> > > > > 
> > > > > Am Dienstag, 8. Januar 2019, 06:03:58 CET schrieb Herbert Xu:
> > > > > 
> > > > > Hi Herbert,
> > > > > 
> > > > > > Are we going to have multiple implementations for the same
> > > > > > KDF? If not then the crypto API is not a good fit.  To
> > > > > > consolidate multiple implementations of the same KDF, simply
> > > > > > provide helpers for them.
> > > > > 
> > > > > It is unlikely to have multiple implementations of a KDF.
> > > > > However, KDFs relate to hashes like block chaining modes to raw
> > > > > block ciphers. Thus a KDF can be applied with different hashes.
> > > > > 
> > > > > My idea was to add template support to RNGs (because KDFs are
> > > > > effectively a type of RNG since they produce an arbitrary
> > > > > output from a fixed input). The KDFs would be a template
> > > > > wrapping hashes.  For example, the CTR-KDF from SP800-108 could
> > > > > be instantiated like kdf-ctr(sha256).
> > > > > 
> > > > > 
> > > > 
> > > > I think that, if the crypto API is going to grow a KDF facility,
> > > > it should be done right. Have a key type or flag or whatever that
> > > > says “this key may *only* be used to derive keys using such-and-
> > > > such algorithm”, and have a helper to derive a key.  That helper
> > > > should take some useful parameters and mix them in:
> > > > 
> > > > - What type of key is being derived?  ECDSA signing key?  HMAC
> > > > key?  AES key?
> > > > 
> > > > - Can user code access the derived key?
> > > > 
> > > > - What is the key’s purpose?  “Encrypt and authenticate a
> > > > hibernation image” would be a purpose.
> > > > 
> > > > - Number of bytes.
> > > > 
> > > > All of these parameters should be mixed in to the key derivation.
> > > > 
> > > > Also, an AE key, even for AES+HMAC, should be just one derived
> > > > key.  If you need 512 bits, ask for a 512-bit key, not two 256-
> > > > bit keys.
> > > 
> > > Actually, it would be enormously helpful if we could reuse these
> > > pieces for the TPM as well.  It has two KDFs: KDFa, which is the
> > > CTR-KDF from SP800-108 and KDFe which is the SP800-56A KDF for
> > > elliptic curve one pass Diffie Hellman, so if we're going to do the
> > > former, I'd really like the latter as well.
> > > 
> > > The way the TPM parametrises input to both KDFs is
> > > 
> > > (hashAlg, key, label, contextU, contextV, bits)
> > > 
> > > Where
> > > 
> > > hashAlg  = the hash algorithm used as the PRF
> > > key  = the input parameter of variable bit size or
> > >the x co-ordinate of the shared point
> > > label= An ASCII string representing the use
> > > contextU = public input U
> > > contextV = public input V
> > > bits = number of output bits
> > > 
> > > Is that a good enough parametrisation (not the only way you
> > > distinguish uses is with the label, which is not
> > > recoverable)?  ContextU and ContextV are simply concatenated to
> > > form the full Context of SP800-108, but we tend to need two
> > > separate inputs (for KDFe they're the public x co-ordinates of the
> > > points of the two inputs to ECDH for instance; in KDFa they're
> > > usually the local and remote nonces).
> > > 
> > > The labels for TPM usage are things like "INTEGRITY" for HMAC keys
> > > or "CFB" when generating an aes128-cfb session key. For KDFe, the
> > > tpm seems to like the label "SECRET".  Although the TPM specifies
> > > fixed short strings for the label, nothing prevents them being
> > > longer like the purpose you state above (essentially we could mix
> > > purpose, use and key type into the label and the contexts).
> > > 
> > 
> > That really ought to cover anything the kernel needs.
> > 
> > But can you explain what's up with with KDFe?  The obvious searches
> > end up with just warnings that the US currently has no government :(
> 
> You mean you can't find SP100-56A because NIST is a government entity
> and it's discontinued its website because of the government shutdown? 
> No idea, I only live here, you'll have to ask a real American.
> 
> ACM does have a copy:
> 
> http://delivery.acm.org/10.1145/221/2206270/SP800-56A_Revision1_Mar08-2007.pdf?ip=50.35.68.20=2206270=OPEN=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1546993111_ed9c8bd24b2f838c829d428aac7f5d71
> 
> > Anyway, if we're talking about the TPM, it seems like the entire
> > "trusted key" mechanism in the kernel is missing the point.  If I
> > want to encrypt something like a hibernation image on a machine with
> > a TPM, it makes essentially no sense to me that we would get a 

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

On Thu, Jan 10, 2019 at 12:39:58AM +0800, joeyli wrote:
> Hi Andy,
>
[...snip] 
> 
> Let's why I encrypt/decrypt data pages one by one, then I copy the
^^^ That's why

> encrypt/decrypt data from buffer page (only one buffer page reserved
> for encrypt/decrypt) to original page. I encreypt pages one by one, but
> I HMAC and verify the whole snapshot image by update mode.
> 
[...snip]
>  
> > Why are you manually supporting three different key types?  Can’t you
> > just somehow support all key types?  And shouldn’t you be verifying
> 
> I only supported two key typs in my patch set, user defined key and
> TPM trusted key. The EFI secure boot did not accept by EFI subsystem.
   ^^^ EFI secure key
   https://lkml.org/lkml/2018/8/5/10

Sorry for I produced too many typo when feeling sleepy...

Thanks a lot!
Joey Lee

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

Hi Andy,

Thanks for your review!

On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote:
> > On Jan 7, 2019, at 9:37 AM, joeyli  wrote:
> >
> > Hi Pavel,
> >
> > Thanks for your review!
> >
> >> On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote:
> >> Hi!
> >>
> >>> This patchset is the implementation of encryption and authentication
> >>> for hibernate snapshot image. The image will be encrypted by AES and
> >>> authenticated by HMAC.
> >>
> >> Ok, so you encrypt.
> >
> > Yes, encryption and authentication.
> >
> >>> The hibernate function can be used to snapshot memory pages to an image,
> >>> then kernel restores the image to memory space in a appropriate time.
> >>> There have secrets in snapshot image and cracker may modifies it for
> >>> hacking system. Encryption and authentication of snapshot image can 
> >>> protect
> >>> the system.
> >>>
> >>> Hibernate function requests the master key through key retention service.
> >>> The snapshot master key can be a trusted key or a user defined key. The
> >>> name of snapshot master key is fixed to "swsusp-kmk". User should loads
> >>> swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> >>> e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> >>
> >> But if userspace has a key, encryption is useless against root.
> >
> > Yes, but this concern is not only for hibernation encryption. This patch
> > set does not provide solution against this concern.
> >
> > The purpose of this patch set is to encrypt and authenticate hibernate
> > snapshot image in kernel space. It also requests key through keyring
> > mechanism. Which means that we can easy to adapt to new key type from
> > keyring in the future.
> >
> > Currently TPM trusted key or user defined key types are not against
> > root. Even using the TPM trusted key, it still can be unsealed by root
> > before the PCRs be capped (unless we capped PCRs in kernel).
> >
> > My solution for keeping the secret by kernel is the EFI secure key type:
> >https://lkml.org/lkml/2018/8/5/31
> >
> > But the EFI boot variable doesn't design for keeping secret, so Windows
> > and OEM/ODM do not use boot variable to keep secret. So this idea can
> > not be accepted. We must think other key type against root.
> >
> >>> The TPM trusted key type is preferred to be the master key. But user
> >>> defined key can also be used for testing or when the platform doesn't
> >>> have TPM. User must be aware that the security of user key relies on
> >>> user space. If the root account be compromised, then the user key will
> >>> easy to be grabbed.
> >>
> >> In the TPM case, does userland have access to the key?
> >
> > In the TPM case, userland can only touch the sealed key blob. So userland
> > doesn't know the real secret. But it has risk that root unseals the key
> > before PCRs be capped.
> >
> >> Please explain your security goals.
> >
> > My security goals:
> >
> > - Encrypt and authicate hibernate snapshot image in kernel space. Userspace
> >  can only touch an encrypted and signed snapshot image.
> 
> Signed?
> 
> I’m not entirely convinced that the keyring mechanism is what you
> want. ISTM that there are two goals here:
> 
> a) Encryption: it should be as hard as can reasonably be arranged to
> extract secrets from a hibernation image.
>
> b) Authentication part 1: it should not be possible for someone in
> possession of a turned-off machine to tamper with the hibernation
> image such that the image, when booted, will leak its secrets. This
> should protect against attackers who don’t know the encryption key.
> 
> c) Authentication part 2: it should be to verify, to the extent
> practical, that the image came from the same machine and was really
> created using hibernation.  Or maybe by the same user.
> 
> For (a) and (b), using an AE mode where the key is protected in some
> reasonable way.  Joey, why are you using HMAC?  Please tell me you’re
> at least doing encrypt-then-MAC.  But why not use a real AE mode like
> AES-GCM?

The reason for using HMAC is the history for development. My first patch
set is only for hibernate authentication. Then I added encryption code on
top of my authentication patches in last version.

I am doing encrypt-then-MAC. My code ecrypts each page by AES then HMAC
whole snapshot image. I feed encrypted data pages

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

[joeyli]

Hi Pavel, 

Thanks for your review!

On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote:
> Hi!
> 
> > This patchset is the implementation of encryption and authentication
> > for hibernate snapshot image. The image will be encrypted by AES and
> > authenticated by HMAC.
> 
> Ok, so you encrypt. 
>

Yes, encryption and authentication. 
 
> > The hibernate function can be used to snapshot memory pages to an image,
> > then kernel restores the image to memory space in a appropriate time.
> > There have secrets in snapshot image and cracker may modifies it for
> > hacking system. Encryption and authentication of snapshot image can protect
> > the system.
> > 
> > Hibernate function requests the master key through key retention service.
> > The snapshot master key can be a trusted key or a user defined key. The
> > name of snapshot master key is fixed to "swsusp-kmk". User should loads
> > swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> > e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> 
> But if userspace has a key, encryption is useless against root.
>

Yes, but this concern is not only for hibernation encryption. This patch
set does not provide solution against this concern.

The purpose of this patch set is to encrypt and authenticate hibernate
snapshot image in kernel space. It also requests key through keyring
mechanism. Which means that we can easy to adapt to new key type from
keyring in the future. 

Currently TPM trusted key or user defined key types are not against
root. Even using the TPM trusted key, it still can be unsealed by root
before the PCRs be capped (unless we capped PCRs in kernel). 

My solution for keeping the secret by kernel is the EFI secure key type:
https://lkml.org/lkml/2018/8/5/31

But the EFI boot variable doesn't design for keeping secret, so Windows
and OEM/ODM do not use boot variable to keep secret. So this idea can
not be accepted. We must think other key type against root. 

> > The TPM trusted key type is preferred to be the master key. But user
> > defined key can also be used for testing or when the platform doesn't
> > have TPM. User must be aware that the security of user key relies on
> > user space. If the root account be compromised, then the user key will
> > easy to be grabbed.
> 
> In the TPM case, does userland have access to the key? 
>

In the TPM case, userland can only touch the sealed key blob. So userland
doesn't know the real secret. But it has risk that root unseals the key
before PCRs be capped.

> Please explain your security goals.
> 

My security goals:

- Encrypt and authicate hibernate snapshot image in kernel space. Userspace
  can only touch an encrypted and signed snapshot image.

- The code of encryption are in kernel. They will be signed and verify with
  kernel binary when secure boot enabled. It's better than using
  unauthenticated userspace code at runtime.

- Using TPM trusted key, at least the security of hibernation aligns with
  other subsystem. e.g. EVM. 

- Using keyring as the key source of hibernation. Then we can easy to
  adapt to new key type against root be compromised. 

> 
> > Lee, Chun-Yi (5):
> >   PM / hibernate: Create snapshot keys handler
> >   PM / hibernate: Generate and verify signature for snapshot image
> >   PM / hibernate: Encrypt snapshot image
> >   PM / hibernate: Erase the snapshot master key in snapshot pages
> >   PM / hibernate: An option to request that snapshot image must be
> > authenticated
> > 

Thanks a lot!
Joey Lee

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Stephan, 

First, thanks for your review!

On Sun, Jan 06, 2019 at 09:01:27AM +0100, Stephan Mueller wrote:
> Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi:
> 
> Hi Chun,
> 
> > This patch adds a snapshot keys handler for using the key retention
> > service api to create keys for snapshot image encryption and
> > authentication.
> > 
> > This handler uses TPM trusted key as the snapshot master key, and the
> > encryption key and authentication key are derived from the snapshot
> > key. The user defined key can also be used as the snapshot master key
> > , but user must be aware that the security of user key relies on user
> > space.
> > 
[...snip]
> > +static int calc_hash(u8 *digest, const u8 *buf, unsigned int buflen,
> > +bool may_sleep)
> > +{
> > +   struct shash_desc *desc;
> > +   int err;
> > +
> > +   desc = kzalloc(sizeof(struct shash_desc) +
> > +  crypto_shash_descsize(hash_tfm),
> > +  may_sleep ? GFP_KERNEL : GFP_ATOMIC);
> 
> Why not using SHASH_DESC_ON_STACK?
>

Because security concern and bad runtime performance. Please looking at
c2cd0b08e1e patch for hibernation. And reference:

https://lore.kernel.org/lkml/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com/T/#u
https://lwn.net/Articles/749064/
 
> > +   if (!desc)
> > +   return -ENOMEM;
> > +
> > +   desc->tfm = hash_tfm;
> > +   desc->flags = may_sleep ? CRYPTO_TFM_REQ_MAY_SLEEP : 0;
> > +   err = crypto_shash_digest(desc, buf, buflen, digest);
> > +   shash_desc_zero(desc);
> > +   kzfree(desc);
> > +
> > +   return err;
> > +}
> > +
> > +static int calc_key_hash(u8 *key, unsigned int key_len, const char *salt,
> > +u8 *hash, bool may_sleep)
> > +{
> > +   unsigned int salted_buf_len;
> > +   u8 *salted_buf;
> > +   int ret;
> > +
> > +   if (!key || !hash_tfm || !hash)
> > +   return -EINVAL;
> > +
> > +   salted_buf_len = strlen(salt) + 1 + SNAPSHOT_KEY_SIZE;
> 
> strlen on binary data? I guess that will not work. May I suggest to hand down 
> the length of salt to this function?
>

hm... The salt is actually a "salt string" that's gave from
snapshot_get_auth_key() or snapshot_get_enc_key(). So I use
strlen() here. I will change the name to salt_string to avoid
confusion. 
 
> > +   salted_buf = kzalloc(salted_buf_len,
> > +   may_sleep ? GFP_KERNEL : GFP_ATOMIC);
> > +   if (!salted_buf)
> > +   return -ENOMEM;
> > +
> > +   strcpy(salted_buf, salt);
> > +   memcpy(salted_buf + strlen(salted_buf) + 1, key, key_len);
> > +
> > +   ret = calc_hash(hash, salted_buf, salted_buf_len, may_sleep);
> > +   memzero_explicit(salted_buf, salted_buf_len);
> > +   kzfree(salted_buf);
> > +
> > +   return ret;
> > +}
> 
> This function looks very much like a key derivation. May I strongly propose 
> to 

Actually key derivation function is modified from the get_derived_key() from
the encrypted.c file in encrypted key.

> use an official KDF type like SP800-108 or HKDF?
> 
> You find the counter-KDF according to SP800-108 in security/keys/dh.c (search 
> for functions *kdf*).
> 
> Or we may start pulling in KDF support into the kernel crypto API via the 
> patches along the line of [1].
> 
> [1] http://www.chronox.de/kdf.html
>

Thanks for your suggestion. I didn't touch any key derivation standard
before. I will study it.

But I still want to use my original function currently. Because the same
logic is also used in trusted key. I will happy to move to SP800-108 or
HKDF when it's available in kernel.  

> > +
> > +/* Derive authentication/encryption key */
> > +static int get_derived_key(u8 *derived_key, const char *derived_type_str,
> > +  bool may_sleep)
[...snip]
> > +static int trusted_key_init(void)
> > +{
> > +   struct trusted_key_payload *tkp;
> > +   struct key *key;
> > +   int err = 0;
> > +
> > +   pr_debug("%s\n", __func__);
> > +
> > +   /* find out swsusp-key */
> > +   key = request_key(_type_trusted, skey.key_name, NULL);
> > +   if (IS_ERR(key)) {
> > +   pr_err("Request key error: %ld\n", PTR_ERR(key));
> > +   err = PTR_ERR(key);
> > +   return err;
> > +   }
> > +
> > +   down_write(>sem);
> > +   tkp = key->payload.data[0];
> > +   if (invalid_key(tkp->key, tkp->key_len)) {
> > +   err = -EINVAL;
> > +   goto key_invalid;
> > +   }
> > +   skey.key_len = tkp->key_len;
> > +   memcpy(skey.key, tkp->key, tkp->key_len);
> > +   /* burn the original key contents */
> > +   memzero_explicit(tkp->key, tkp->key_len);
> > +
> > +key_invalid:
> > +   up_write(>sem);
> > +   key_put(key);
> > +
> > +   return err;
> > +}
> > +
> > +static int user_key_init(void)
> 
> This function and trusted_key_init look very similar - could they be 
> collapsed 
> into one function?
>

The data structure is different between trusted key with user key. I will try to
extract the duplicate part but may not collapse into one.
 
> > +{
> > +   

Re: [PATCH 0/2] [RFC] sysfs: Add hook for checking the file capability of opener

[joeyli]

Hi Greg, 

Thanks for your review!

On Sun, Dec 30, 2018 at 03:45:06PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Dec 30, 2018 at 09:28:54PM +0800, Lee, Chun-Yi wrote:
> > There have some discussion in the following mail loop about checking
> > capability in sysfs write handler:
> > https://lkml.org/lkml/2018/9/13/978
> 
> A sysfs callback should not care about stuff like this.
> 
> Worst case, do a simple:
>   if (!capable(CAP_FOO))
>   return -EPERM
> 
> you don't care or need to worry about the file handle for that at all,
> right?
>

The capable() can be bypassed. Unprivileged process may reads or writes
those sysfs if file permission be relaxed by root for non-root user.
 
> > Sometimes we check the capability in sysfs implementation by using
> > capable function.
> 
> Which should be fine, right?
>

If file permission is enough to restrict sysfs that can only be used
by root. Why do some sysfs interfaces use capable()? It's not
redundancy? 
 
> > But the checking can be bypassed by opening sysfs
> > file within an unprivileged process then writing the file within a
> > privileged process. The tricking way has been exposed by Andy Lutomirski
> > for CVE-2013-1959.
> 
> And who does this for a sysfs file?  And why?
>

Just want to bypass the capable() checking. 
 
> > Because the sysfs_ops does not forward the file descriptor to the
> > show/store callback, there doesn't have chance to check the capability
> > of file's opener.
> 
> Which is by design.  If you care about open, you are using sysfs wrong.
>

OK~ So the sysfs doesn't care opener's capability.
 
> > This patch adds the hook to sysfs_ops that allows
> > different implementation in object and attribute levels for checking
> > file capable before accessing sysfs interfaces.
> 
> No, please no.
>
> > The callback function of kobject sysfs_ops is the first implementation
> > of new hook. It casts attribute to kobj_attribute then calls the file
> > capability callback function of attribute level. The same logic can
> > be implemented in other sysfs file types, like: device, driver and
> > bus type. 
> > 
> > The capability checking logic in wake_lock/wake_unlock sysfs interface
> > is the first example for kobject. It will check the opener's capability.
> 
> Why doesn't the file permission of that sysfs file determine who can or
> can not write to that file?
>

I agree that the file permission can restrict the writer of sysfs. But,
I still confused for why do some sysfs interface use capable()?

Thanks a lot!
Joey Lee 

Re: [PATCH 2/2] PM / Sleep: Check the file capability when writing wake lock interface

[joeyli]

Hi Greg,

On Sun, Dec 30, 2018 at 03:48:35PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Dec 30, 2018 at 09:28:56PM +0800, Lee, Chun-Yi wrote:
> > The wake lock/unlock sysfs interfaces check that the writer must has
> > CAP_BLOCK_SUSPEND capability. But the checking logic can be bypassed
> > by opening sysfs file within an unprivileged process and then writing
> > the file within a privileged process. The tricking way has been exposed
> > by Andy Lutomirski in CVE-2013-1959.
> 
> Don't you mean "open by privileged and then written by unprivileged?"
> Or if not, exactly how is this a problem?  You check the capabilities
> when you do the write and if that is not allowed then, well
>

Sorry for I didn't provide clear explanation.

The privileged means CAP_BLOCK_SUSPEND but not file permission. The file 
permission
has already relaxed for non-root user. Then the expected behavior is that 
non-root
process must has CAP_BLOCK_SUSPEND capability for writing wake_lock sysfs.

But, the CAP_BLOCK_SUSPEND restrict can be bypassed:

int main(int argc, char* argv[])
{
int fd, ret = 0;

fd = open("/sys/power/wake_lock", O_RDWR);
if (fd < 0)
err(1, "open wake_lock");

if (dup2(fd, 1) != 1)   // overwrite the stdout with wake_lock
err(1, "dup2");
sleep(1);
execl("./string", "string");//string has capability

return ret;
}

This program is an unpriviledged process (has no CAP_BLOCK_SUSPEND), it opened
wake_lock sysfs and overwrited stdout. Then it executes the "string" program
that has CAP_BLOCK_SUSPEND. The string program writes to stdout, which means
that it writes to wake_lock. So an unpriviledged opener can trick an priviledged
writer for writing sysfs.  
 
> And you are checking the namespace of the person trying to do the write
> when the write happens, which is correct here, right?
> 
> If you really want to mess with wake locks in a namespaced environment,
> then put it in a real namespaced environment, which is {HUGE HINT} not
> sysfs.
>

I don't want to mess with wake locks in namespace.
 
> So no, this patch isn't ok...
>

Thanks a lot!
Joey Lee 

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[joeyli]

Hi Yu Chen,

Thanks for your response!

On Tue, Dec 11, 2018 at 11:12:21AM +0800, Yu Chen wrote:
> Hi Joey,
> On Mon, Dec 10, 2018 at 02:31:53PM +0800, joeyli wrote:
> > Hi Chen Yu and ACPI experts,
> > 
> > On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote:
> > > According to current implementation of acpi_pad driver,
> > > it does not make sense to spawn any power saving threads
> > > on the cpus which are already idle - it might bring
> > > unnecessary overhead on these idle cpus and causes power
> > > waste. So verify the condition that if the number of 'busy'
> > > cpus exceeds the amount of the 'forced idle' cpus is met.
> > > This is applicable due to round-robin attribute of the
> > > power saving threads, otherwise ignore the setting/ACPI
> > > notification.
> > > 
> > > Suggested-by: Lenny Szubowicz 
> > > Suggested-by: Len Brown 
> > > Cc: "Rafael J. Wysocki" 
> > > Cc: Lenny Szubowicz 
> > > Cc: Len Brown 
> > > Cc: Jacob Pan 
> > > Cc: Rui Zhang 
> > > Cc: linux-a...@vger.kernel.org
> > > Signed-off-by: Chen Yu 
> > 
> > Do you have any news for this patch? Why it did not merged by kernel
> > maineline?
> > 
> We are evaluating if this could be integrated into idle injection framework.
> May I know if there's any requirement/background from SUSE on this?
> 

I am also looking at your patch and idle injection framework. Currently I do not
have good suggestion for your patches yet. But I will try to ready my knowledge 
when
you send out new version.

Thanks a lot!
Joey Lee 

> > 
> > > ---
> > >  drivers/acpi/acpi_pad.c | 52 
> > > -
> > >  1 file changed, 51 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> > > index 552c1f7..515e60e 100644
> > > --- a/drivers/acpi/acpi_pad.c
> > > +++ b/drivers/acpi/acpi_pad.c
> > > @@ -254,12 +254,62 @@ static void set_power_saving_task_num(unsigned int 
> > > num)
> > >   }
> > >  }
> > >  
> > > +/*
> > > + * Extra acpi_pad threads should not be created until
> > > + * the requested idle count is less than/equals to the
> > > + * number of the busy cpus - it does not make sense to
> > > + * throttle the idle cpus.
> > > + */
> > > +#define SAMPLE_INTERVAL_JIF  20
> > > +
> > > +static u64 get_idle_time(int cpu)
> > > +{
> > > + u64 idle, idle_usecs = -1ULL;
> > > +
> > > + idle_usecs = get_cpu_idle_time_us(cpu, NULL);
> > > +
> > > + if (idle_usecs == -1ULL)
> > > + idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
> > > + else
> > > + idle = idle_usecs * NSEC_PER_USEC;
> > > +
> > > + return idle;
> > > +}
> > > +
> > > +static bool idle_nr_valid(unsigned int num_cpus)
> > > +{
> > > + int busy_nr = 0, i = 0, load_thresh = 100 - idle_pct;
> > > +
> > > + if (!num_cpus)
> > > + return true;
> > > +
> > > + for_each_online_cpu(i) {
> > > + u64 wall_time, idle_time;
> > > + unsigned int elapsed_delta, idle_delta, load;
> > > +
> > > + wall_time = jiffies64_to_nsecs(get_jiffies_64());
> > > + idle_time = get_idle_time(i);
> > > + /* Wait and see... */
> > > + schedule_timeout_uninterruptible(SAMPLE_INTERVAL_JIF);
> > > +
> > > + idle_delta = get_idle_time(i) - idle_time;
> > > + elapsed_delta = jiffies64_to_nsecs(get_jiffies_64()) - 
> > > wall_time;
> > > + idle_delta = (idle_delta > elapsed_delta) ? elapsed_delta : 
> > > idle_delta;
> > > + load = 100 * (elapsed_delta - idle_delta) / elapsed_delta;
> > > + if (load >= load_thresh)
> > > + busy_nr++;
> > > + }
> > > +
> > > + return (busy_nr >= num_cpus) ? true : false;
> > > +}
> > > +
> > >  static void acpi_pad_idle_cpus(unsigned int num_cpus)
> > >  {
> > >   get_online_cpus();
> > >  
> > >   num_cpus = min_t(unsigned int, num_cpus, num_online_cpus());
> > > - set_power_saving_task_num(num_cpus);
> > > + if (idle_nr_valid(num_cpus))
> > > + set_power_saving_task_num(num_cpus);
> > >  
> > >   put_online_cpus();
> > >  }
> > > -- 
> > > 2.7.4
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[joeyli]

Hi Chen Yu and ACPI experts,

On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote:
> According to current implementation of acpi_pad driver,
> it does not make sense to spawn any power saving threads
> on the cpus which are already idle - it might bring
> unnecessary overhead on these idle cpus and causes power
> waste. So verify the condition that if the number of 'busy'
> cpus exceeds the amount of the 'forced idle' cpus is met.
> This is applicable due to round-robin attribute of the
> power saving threads, otherwise ignore the setting/ACPI
> notification.
> 
> Suggested-by: Lenny Szubowicz 
> Suggested-by: Len Brown 
> Cc: "Rafael J. Wysocki" 
> Cc: Lenny Szubowicz 
> Cc: Len Brown 
> Cc: Jacob Pan 
> Cc: Rui Zhang 
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Chen Yu 

Do you have any news for this patch? Why it did not merged by kernel
maineline?

Thanks a lot!
Joey Lee

> ---
>  drivers/acpi/acpi_pad.c | 52 
> -
>  1 file changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index 552c1f7..515e60e 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -254,12 +254,62 @@ static void set_power_saving_task_num(unsigned int num)
>   }
>  }
>  
> +/*
> + * Extra acpi_pad threads should not be created until
> + * the requested idle count is less than/equals to the
> + * number of the busy cpus - it does not make sense to
> + * throttle the idle cpus.
> + */
> +#define SAMPLE_INTERVAL_JIF  20
> +
> +static u64 get_idle_time(int cpu)
> +{
> + u64 idle, idle_usecs = -1ULL;
> +
> + idle_usecs = get_cpu_idle_time_us(cpu, NULL);
> +
> + if (idle_usecs == -1ULL)
> + idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
> + else
> + idle = idle_usecs * NSEC_PER_USEC;
> +
> + return idle;
> +}
> +
> +static bool idle_nr_valid(unsigned int num_cpus)
> +{
> + int busy_nr = 0, i = 0, load_thresh = 100 - idle_pct;
> +
> + if (!num_cpus)
> + return true;
> +
> + for_each_online_cpu(i) {
> + u64 wall_time, idle_time;
> + unsigned int elapsed_delta, idle_delta, load;
> +
> + wall_time = jiffies64_to_nsecs(get_jiffies_64());
> + idle_time = get_idle_time(i);
> + /* Wait and see... */
> + schedule_timeout_uninterruptible(SAMPLE_INTERVAL_JIF);
> +
> + idle_delta = get_idle_time(i) - idle_time;
> + elapsed_delta = jiffies64_to_nsecs(get_jiffies_64()) - 
> wall_time;
> + idle_delta = (idle_delta > elapsed_delta) ? elapsed_delta : 
> idle_delta;
> + load = 100 * (elapsed_delta - idle_delta) / elapsed_delta;
> + if (load >= load_thresh)
> + busy_nr++;
> + }
> +
> + return (busy_nr >= num_cpus) ? true : false;
> +}
> +
>  static void acpi_pad_idle_cpus(unsigned int num_cpus)
>  {
>   get_online_cpus();
>  
>   num_cpus = min_t(unsigned int, num_cpus, num_online_cpus());
> - set_power_saving_task_num(num_cpus);
> + if (idle_nr_valid(num_cpus))
> + set_power_saving_task_num(num_cpus);
>  
>   put_online_cpus();
>  }
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Any, Jann,

On Wed, Oct 03, 2018 at 03:08:12PM -0700, Andy Lutomirski wrote:
> On Tue, Oct 2, 2018 at 12:36 PM Jann Horn  wrote:
> >
> > +Andy for opinions on things in write handlers
> > +Mimi Zohar as EVM maintainer
> >
> > On Tue, Oct 2, 2018 at 9:55 AM joeyli  wrote:
> > > On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi  
> > > > wrote:
> > > > > This patch adds a snapshot keys handler for using the key retention
> > > > > service api to create keys for snapshot image encryption and
> > > > > authentication.
> > > [...snip]
> > > > > +static ssize_t disk_kmk_store(struct kobject *kobj, struct 
> > > > > kobj_attribute *attr,
> > > > > + const char *buf, size_t n)
> > > > > +{
> > > > > +   int error = 0;
> > > > > +   char *p;
> > > > > +   int len;
> > > > > +
> > > > > +   if (!capable(CAP_SYS_ADMIN))
> > > > > +   return -EPERM;
> > > >
> > > > This is wrong, you can't use capable() in a write handler. You'd have
> > > > to use file_ns_capable(), and I think sysfs currently doesn't give you
> > > > a pointer to the struct file.
> > > > If you want to do this in a write handler, you'll have to either get
> > > > rid of this check or plumb through the cred struct pointer.
> > > > Alternatively, you could use some interface that doesn't go through a
> > > > write handler.
> > > >
> > >
> > > Thank you for point out this problem.
> > >
> > > Actually the evm_write_key() is the example for my code. The
> > > difference is that evm creates interface file on securityfs, but my
> > > implementation is on sysfs:
> > >
> > > security/integrity/evm/evm_secfs.c
> > >
> > > static ssize_t evm_write_key(struct file *file, const char __user *buf,
> > >  size_t count, loff_t *ppos)
> > > {
> > > int i, ret;
> > >
> > > if (!capable(CAP_SYS_ADMIN) || (evm_initialized & EVM_SETUP))
> > > return -EPERM;
> 
> Yeah, that's a bug.
> 
> > > ...
> > >
> > > On the other hand, the writing handler of /sys/power/wake_lock also
> > > uses capable() to check the CAP_BLOCK_SUSPEND capability:
> > >
> > > kernel/power/main.c
> > > static ssize_t wake_lock_store(struct kobject *kobj,
> > >struct kobj_attribute *attr,
> > >const char *buf, size_t n)
> > > {
> > > int error = pm_wake_lock(buf);
> > > return error ? error : n;
> > > }
> > > power_attr(wake_lock);
> > >
> > > kernel/power/wakelock.c
> > > int pm_wake_lock(const char *buf)
> > > {
> > > ...
> > > if (!capable(CAP_BLOCK_SUSPEND))
> > > return -EPERM;
> > > ...
> 
> Also a bug.
> 
> > >
> > >
> > > So I confused for when can capable() be used in sysfs interface? Is
> > > capable() only allowed in reading handler? Why the writing handler
> > > of securityfs can use capable()?
> >
> > They can't, they're all wrong. :P All of these capable() checks in
> > write handlers have to be assumed to be ineffective. But it's not a
> > big deal because you still need UID 0 to access these files.
> 
> Why are there capability checks at all?
> 
> >
> > > > > +static int user_key_init(void)
> > > > > +{
> > > > > +   struct user_key_payload *ukp;
> > > > > +   struct key *key;
> > > > > +   int err = 0;
> > > > > +
> > > > > +   pr_debug("%s\n", __func__);
> > > > > +
> > > > > +   /* find out swsusp-key */
> > > > > +   key = request_key(_type_user, skey.key_name, NULL);
> > > >
> > > > request_key() looks at current's keyring. That shouldn't happen in a
> > > > write handler.
> > > >
> > >
> > > The evm_write_key() also uses request_key() but it's on securityfs. Should
> > > I move my sysfs interface to securityfs?
> >
> > I don't think you should be doing this in the context of any
> > filesystem. If EVM does that, EVM is doing it wrong.
> 
> EVM sounds buggy.
> 
> In general if you look at current *at all* in an implementation of
> write() *in any filesystem*, you are doing it wrong.

I have read CVE-2013-1959... Thanks for Jann and Andy's review.

I will create the sysfs interface through other way, then using 
file_ns_capable() for capability checking in next version.

Thanks a lot!
Joey Lee

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Any, Jann,

On Wed, Oct 03, 2018 at 03:08:12PM -0700, Andy Lutomirski wrote:
> On Tue, Oct 2, 2018 at 12:36 PM Jann Horn  wrote:
> >
> > +Andy for opinions on things in write handlers
> > +Mimi Zohar as EVM maintainer
> >
> > On Tue, Oct 2, 2018 at 9:55 AM joeyli  wrote:
> > > On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi  
> > > > wrote:
> > > > > This patch adds a snapshot keys handler for using the key retention
> > > > > service api to create keys for snapshot image encryption and
> > > > > authentication.
> > > [...snip]
> > > > > +static ssize_t disk_kmk_store(struct kobject *kobj, struct 
> > > > > kobj_attribute *attr,
> > > > > + const char *buf, size_t n)
> > > > > +{
> > > > > +   int error = 0;
> > > > > +   char *p;
> > > > > +   int len;
> > > > > +
> > > > > +   if (!capable(CAP_SYS_ADMIN))
> > > > > +   return -EPERM;
> > > >
> > > > This is wrong, you can't use capable() in a write handler. You'd have
> > > > to use file_ns_capable(), and I think sysfs currently doesn't give you
> > > > a pointer to the struct file.
> > > > If you want to do this in a write handler, you'll have to either get
> > > > rid of this check or plumb through the cred struct pointer.
> > > > Alternatively, you could use some interface that doesn't go through a
> > > > write handler.
> > > >
> > >
> > > Thank you for point out this problem.
> > >
> > > Actually the evm_write_key() is the example for my code. The
> > > difference is that evm creates interface file on securityfs, but my
> > > implementation is on sysfs:
> > >
> > > security/integrity/evm/evm_secfs.c
> > >
> > > static ssize_t evm_write_key(struct file *file, const char __user *buf,
> > >  size_t count, loff_t *ppos)
> > > {
> > > int i, ret;
> > >
> > > if (!capable(CAP_SYS_ADMIN) || (evm_initialized & EVM_SETUP))
> > > return -EPERM;
> 
> Yeah, that's a bug.
> 
> > > ...
> > >
> > > On the other hand, the writing handler of /sys/power/wake_lock also
> > > uses capable() to check the CAP_BLOCK_SUSPEND capability:
> > >
> > > kernel/power/main.c
> > > static ssize_t wake_lock_store(struct kobject *kobj,
> > >struct kobj_attribute *attr,
> > >const char *buf, size_t n)
> > > {
> > > int error = pm_wake_lock(buf);
> > > return error ? error : n;
> > > }
> > > power_attr(wake_lock);
> > >
> > > kernel/power/wakelock.c
> > > int pm_wake_lock(const char *buf)
> > > {
> > > ...
> > > if (!capable(CAP_BLOCK_SUSPEND))
> > > return -EPERM;
> > > ...
> 
> Also a bug.
> 
> > >
> > >
> > > So I confused for when can capable() be used in sysfs interface? Is
> > > capable() only allowed in reading handler? Why the writing handler
> > > of securityfs can use capable()?
> >
> > They can't, they're all wrong. :P All of these capable() checks in
> > write handlers have to be assumed to be ineffective. But it's not a
> > big deal because you still need UID 0 to access these files.
> 
> Why are there capability checks at all?
> 
> >
> > > > > +static int user_key_init(void)
> > > > > +{
> > > > > +   struct user_key_payload *ukp;
> > > > > +   struct key *key;
> > > > > +   int err = 0;
> > > > > +
> > > > > +   pr_debug("%s\n", __func__);
> > > > > +
> > > > > +   /* find out swsusp-key */
> > > > > +   key = request_key(_type_user, skey.key_name, NULL);
> > > >
> > > > request_key() looks at current's keyring. That shouldn't happen in a
> > > > write handler.
> > > >
> > >
> > > The evm_write_key() also uses request_key() but it's on securityfs. Should
> > > I move my sysfs interface to securityfs?
> >
> > I don't think you should be doing this in the context of any
> > filesystem. If EVM does that, EVM is doing it wrong.
> 
> EVM sounds buggy.
> 
> In general if you look at current *at all* in an implementation of
> write() *in any filesystem*, you are doing it wrong.

I have read CVE-2013-1959... Thanks for Jann and Andy's review.

I will create the sysfs interface through other way, then using 
file_ns_capable() for capability checking in next version.

Thanks a lot!
Joey Lee

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Jann,

Thanks for your review and very sorry for my delay!

On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> +cc keyrings list
> 
> On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi  wrote:
> > This patch adds a snapshot keys handler for using the key retention
> > service api to create keys for snapshot image encryption and
> > authentication.
[...snip]
> > +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > + const char *buf, size_t n)
> > +{
> > +   int error = 0;
> > +   char *p;
> > +   int len;
> > +
> > +   if (!capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> 
> This is wrong, you can't use capable() in a write handler. You'd have
> to use file_ns_capable(), and I think sysfs currently doesn't give you
> a pointer to the struct file.
> If you want to do this in a write handler, you'll have to either get
> rid of this check or plumb through the cred struct pointer.
> Alternatively, you could use some interface that doesn't go through a
> write handler.
>

Thank you for point out this problem.

Actually the evm_write_key() is the example for my code. The
difference is that evm creates interface file on securityfs, but my
implementation is on sysfs:

security/integrity/evm/evm_secfs.c

static ssize_t evm_write_key(struct file *file, const char __user *buf,
 size_t count, loff_t *ppos)
{
int i, ret;

if (!capable(CAP_SYS_ADMIN) || (evm_initialized & EVM_SETUP)) 
return -EPERM;
...

On the other hand, the writing handler of /sys/power/wake_lock also
uses capable() to check the CAP_BLOCK_SUSPEND capability: 

kernel/power/main.c 
static ssize_t wake_lock_store(struct kobject *kobj,
   struct kobj_attribute *attr,
   const char *buf, size_t n)
{
int error = pm_wake_lock(buf);
return error ? error : n;
}
power_attr(wake_lock);

kernel/power/wakelock.c
int pm_wake_lock(const char *buf)
{
...
if (!capable(CAP_BLOCK_SUSPEND))
return -EPERM;
...


So I confused for when can capable() be used in sysfs interface? Is
capable() only allowed in reading handler? Why the writing handler
of securityfs can use capable()?

> > +
> > +static int user_key_init(void)
> > +{
> > +   struct user_key_payload *ukp;
> > +   struct key *key;
> > +   int err = 0;
> > +
> > +   pr_debug("%s\n", __func__);
> > +
> > +   /* find out swsusp-key */
> > +   key = request_key(_type_user, skey.key_name, NULL);
> 
> request_key() looks at current's keyring. That shouldn't happen in a
> write handler.
>

The evm_write_key() also uses request_key() but it's on securityfs. Should
I move my sysfs interface to securityfs?

> > +   if (IS_ERR(key)) {
> > +   pr_err("Request key error: %ld\n", PTR_ERR(key));
> > +   err = PTR_ERR(key);
> > +   return err;
> > +   }
> > +
> > +   down_write(>sem);
> > +   ukp = user_key_payload_locked(key);
> > +   if (!ukp) {
> > +   /* key was revoked before we acquired its semaphore */
> > +   err = -EKEYREVOKED;
> > +   goto key_invalid;
> > +   }
> > +   if (invalid_key(ukp->data, ukp->datalen)) {
> > +   err = -EINVAL;
> > +   goto key_invalid;
> > +   }
> > +   skey.key_len = ukp->datalen;
> > +   memcpy(skey.key, ukp->data, ukp->datalen);
> > +   /* burn the original key contents */
> > +   memzero_explicit(ukp->data, ukp->datalen);
> 
> You just zero out the contents of the supplied key? That seems very
> unidiomatic for the keys subsystem, and makes me wonder why you're
> using the keys subsystem for this in the first place. It doesn't look
> like normal use of the keys subsystem.
> 

Because I want that only one decrypted key in kernel memory. Then hibernation
can handle the key more easy. In evm_init_key(), it also burned the key
contents after evm key be initialled: 

security/integrity/evm/evm_crypto.c
int evm_init_key(void)
{
[...snip]
/* burn the original key contents */
memset(ekp->decrypted_data, 0, ekp->decrypted_datalen);
up_read(_key->sem);
key_put(evm_key);
return rc;
}

The keys subsystem already handles the interactive with userland and TPM.
That's the reason for using keys subsystem in hibernation. 

> > +key_invalid:
> > +   up_write(>sem);
> > +   key_put(key);
> > +
> > +   return err;
> > +}
> > +
> > +/* this function may sleeps */
> > +int snapshot_key_init(void)
> > +{
> > +   int err;
> > +
> > +   pr_debug("%s\n", __func__);
> > +
> > +   if (skey.initialized)
> > +   return 0;
> > +
> > +   hash_tfm = crypto_alloc_shash(hash_alg, 0, CRYPTO_ALG_ASYNC);
> > +   if (IS_ERR(hash_tfm)) {
> > +   pr_err("Can't allocate %s transform: %ld\n",
> > +

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Jann,

Thanks for your review and very sorry for my delay!

On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> +cc keyrings list
> 
> On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi  wrote:
> > This patch adds a snapshot keys handler for using the key retention
> > service api to create keys for snapshot image encryption and
> > authentication.
[...snip]
> > +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > + const char *buf, size_t n)
> > +{
> > +   int error = 0;
> > +   char *p;
> > +   int len;
> > +
> > +   if (!capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> 
> This is wrong, you can't use capable() in a write handler. You'd have
> to use file_ns_capable(), and I think sysfs currently doesn't give you
> a pointer to the struct file.
> If you want to do this in a write handler, you'll have to either get
> rid of this check or plumb through the cred struct pointer.
> Alternatively, you could use some interface that doesn't go through a
> write handler.
>

Thank you for point out this problem.

Actually the evm_write_key() is the example for my code. The
difference is that evm creates interface file on securityfs, but my
implementation is on sysfs:

security/integrity/evm/evm_secfs.c

static ssize_t evm_write_key(struct file *file, const char __user *buf,
 size_t count, loff_t *ppos)
{
int i, ret;

if (!capable(CAP_SYS_ADMIN) || (evm_initialized & EVM_SETUP)) 
return -EPERM;
...

On the other hand, the writing handler of /sys/power/wake_lock also
uses capable() to check the CAP_BLOCK_SUSPEND capability: 

kernel/power/main.c 
static ssize_t wake_lock_store(struct kobject *kobj,
   struct kobj_attribute *attr,
   const char *buf, size_t n)
{
int error = pm_wake_lock(buf);
return error ? error : n;
}
power_attr(wake_lock);

kernel/power/wakelock.c
int pm_wake_lock(const char *buf)
{
...
if (!capable(CAP_BLOCK_SUSPEND))
return -EPERM;
...


So I confused for when can capable() be used in sysfs interface? Is
capable() only allowed in reading handler? Why the writing handler
of securityfs can use capable()?

> > +
> > +static int user_key_init(void)
> > +{
> > +   struct user_key_payload *ukp;
> > +   struct key *key;
> > +   int err = 0;
> > +
> > +   pr_debug("%s\n", __func__);
> > +
> > +   /* find out swsusp-key */
> > +   key = request_key(_type_user, skey.key_name, NULL);
> 
> request_key() looks at current's keyring. That shouldn't happen in a
> write handler.
>

The evm_write_key() also uses request_key() but it's on securityfs. Should
I move my sysfs interface to securityfs?

> > +   if (IS_ERR(key)) {
> > +   pr_err("Request key error: %ld\n", PTR_ERR(key));
> > +   err = PTR_ERR(key);
> > +   return err;
> > +   }
> > +
> > +   down_write(>sem);
> > +   ukp = user_key_payload_locked(key);
> > +   if (!ukp) {
> > +   /* key was revoked before we acquired its semaphore */
> > +   err = -EKEYREVOKED;
> > +   goto key_invalid;
> > +   }
> > +   if (invalid_key(ukp->data, ukp->datalen)) {
> > +   err = -EINVAL;
> > +   goto key_invalid;
> > +   }
> > +   skey.key_len = ukp->datalen;
> > +   memcpy(skey.key, ukp->data, ukp->datalen);
> > +   /* burn the original key contents */
> > +   memzero_explicit(ukp->data, ukp->datalen);
> 
> You just zero out the contents of the supplied key? That seems very
> unidiomatic for the keys subsystem, and makes me wonder why you're
> using the keys subsystem for this in the first place. It doesn't look
> like normal use of the keys subsystem.
> 

Because I want that only one decrypted key in kernel memory. Then hibernation
can handle the key more easy. In evm_init_key(), it also burned the key
contents after evm key be initialled: 

security/integrity/evm/evm_crypto.c
int evm_init_key(void)
{
[...snip]
/* burn the original key contents */
memset(ekp->decrypted_data, 0, ekp->decrypted_datalen);
up_read(_key->sem);
key_put(evm_key);
return rc;
}

The keys subsystem already handles the interactive with userland and TPM.
That's the reason for using keys subsystem in hibernation. 

> > +key_invalid:
> > +   up_write(>sem);
> > +   key_put(key);
> > +
> > +   return err;
> > +}
> > +
> > +/* this function may sleeps */
> > +int snapshot_key_init(void)
> > +{
> > +   int err;
> > +
> > +   pr_debug("%s\n", __func__);
> > +
> > +   if (skey.initialized)
> > +   return 0;
> > +
> > +   hash_tfm = crypto_alloc_shash(hash_alg, 0, CRYPTO_ALG_ASYNC);
> > +   if (IS_ERR(hash_tfm)) {
> > +   pr_err("Can't allocate %s transform: %ld\n",
> > +

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Yu Chen, 

Thanks for your review and very sorry for my delay!

On Thu, Sep 13, 2018 at 09:58:32PM +0800, Yu Chen wrote:
> On Wed, Sep 12, 2018 at 10:23:33PM +0800, Lee, Chun-Yi wrote:
> > This patch adds a snapshot keys handler for using the key retention
> > service api to create keys for snapshot image encryption and
> > authentication.
> > 
> > This handler uses TPM trusted key as the snapshot master key, and the
> > encryption key and authentication key are derived from the snapshot
> > key. The user defined key can also be used as the snapshot master key
> > , but user must be aware that the security of user key relies on user
> > space.
> > 
> In case the kernel provides mechanism to generate key from passphase,
> the master key could also be generated in kernel space other than TPM.
> It seems than snapshot_key_init() is easy to add the interface for that,
> right?

The user defined key can be used to carry the blob from user space. User
sapce can use keyctl tool to enroll the blob. We can design a structure of
blob that it carries the hash of passphase, salt... so on. Then kernel
parses the blob to generate the key for encryption/authentication.

> > The name of snapshot key is fixed to "swsusp-kmk". User should use
> > the keyctl tool to load the key blob to root's user keyring. e.g.
> > 
> >  # /bin/keyctl add trusted swsusp-kmk "load `cat swsusp-kmk.blob`" @u
> > 
> > or create a new user key. e.g.
> > 
> >  # /bin/keyctl add user swsusp-kmk password @u

The above password can be a blob. The user defined key can carries the
blob to kernel. We can design the blob with userland tool later.

> > 
> > Then the disk_kmk sysfs file can be used to trigger the initialization
> > of snapshot key:
> > 
> >  # echo 1 > /sys/power/disk_kmk
> > 
> > After the initialization be triggered, the secret in the payload of
> > swsusp-key will be copied by hibernation and be erased. Then user can
> > use keyctl to remove swsusp-kmk key from root's keyring.
> > 
> > If user does not trigger the initialization by disk_kmk file after
> > swsusp-kmk be loaded to kernel. Then the snapshot key will be
> > initialled when hibernation be triggered.
> > 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Pavel Machek 
> > Cc: Chen Yu 
> > Cc: Oliver Neukum 
> > Cc: Ryan Chen 
> > Cc: David Howells 
> > Cc: Giovanni Gherdovich 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
[...snip]
> > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> > index abef759de7c8..18d13cbf0591 100644
> > --- a/kernel/power/hibernate.c
> > +++ b/kernel/power/hibernate.c
> > @@ -1034,6 +1034,39 @@ static ssize_t disk_store(struct kobject *kobj, 
> > struct kobj_attribute *attr,
> >  
> >  power_attr(disk);
> >  
> > +#ifdef CONFIG_HIBERNATION_ENC_AUTH
> > +static ssize_t disk_kmk_show(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > +char *buf)
> > +{
> > +   if (snapshot_key_initialized())
> > +   return sprintf(buf, "initialized\n");
> > +   else
> > +   return sprintf(buf, "uninitialized\n");
> > +}
> > +
> > +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > + const char *buf, size_t n)
> > +{
> Does kmk mean kernel master key? It might looks unclear from first glance,
> how about disk_genkey_store()?

Yes, it's the kernel maskter key for disk (hibernate).

The sysfs interfaces is used to load the master key from keyring, then
kernel parses the encrypted key or user defined key to grab the plaintext
key. So sysfs triggered the initial process of the master key.

Even user space didn't trigger the process through sysfs, kernel will
still runs the initial process when hibernation be triggered. Then
kernel uses the master key to derive encrypte key and authenticate key. 

I prefer to keep the name of sysfs and the function name. 

> > +   int error = 0;
> > +   char *p;
> > +   int len;
> > +
> > +   if (!capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> > +
> > +   p = memchr(buf, '\n', n);
> > +   len = p ? p - buf : n;
> > +   if (strncmp(buf, "1", len))
> > +   return -EINVAL;
> Why user is not allowed to disable(remove) it by
> echo 0 ?

Similar with evm, this sysfs interface gives user space a chance
to ask kernel to initial master key. Once the master key be
initialled and loaded, kernel doesn't want the key to be removed
because the key is unsealed by TPM. The PCRs may already capped
then there have no other master key can be unsealed and enrolled.

So, I prefer that do not give user space the function to
remove an enrolled master key. Once the master key be loaded,
kernel will use the key to encrypt snapshot image.   

> > +
> > +   error = snapshot_key_init();
> > +
> > +   return error ? error : n;
> > +}
> > +
> > +power_attr(disk_kmk);
> > +#endif /* !CONFIG_HIBERNATION_ENC_AUTH */
[...snip]
> > diff --git a/kernel/power/snapshot_key.c b/kernel/power/snapshot_key.c
> > new file mode 100644
> > index 

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Yu Chen, 

Thanks for your review and very sorry for my delay!

On Thu, Sep 13, 2018 at 09:58:32PM +0800, Yu Chen wrote:
> On Wed, Sep 12, 2018 at 10:23:33PM +0800, Lee, Chun-Yi wrote:
> > This patch adds a snapshot keys handler for using the key retention
> > service api to create keys for snapshot image encryption and
> > authentication.
> > 
> > This handler uses TPM trusted key as the snapshot master key, and the
> > encryption key and authentication key are derived from the snapshot
> > key. The user defined key can also be used as the snapshot master key
> > , but user must be aware that the security of user key relies on user
> > space.
> > 
> In case the kernel provides mechanism to generate key from passphase,
> the master key could also be generated in kernel space other than TPM.
> It seems than snapshot_key_init() is easy to add the interface for that,
> right?

The user defined key can be used to carry the blob from user space. User
sapce can use keyctl tool to enroll the blob. We can design a structure of
blob that it carries the hash of passphase, salt... so on. Then kernel
parses the blob to generate the key for encryption/authentication.

> > The name of snapshot key is fixed to "swsusp-kmk". User should use
> > the keyctl tool to load the key blob to root's user keyring. e.g.
> > 
> >  # /bin/keyctl add trusted swsusp-kmk "load `cat swsusp-kmk.blob`" @u
> > 
> > or create a new user key. e.g.
> > 
> >  # /bin/keyctl add user swsusp-kmk password @u

The above password can be a blob. The user defined key can carries the
blob to kernel. We can design the blob with userland tool later.

> > 
> > Then the disk_kmk sysfs file can be used to trigger the initialization
> > of snapshot key:
> > 
> >  # echo 1 > /sys/power/disk_kmk
> > 
> > After the initialization be triggered, the secret in the payload of
> > swsusp-key will be copied by hibernation and be erased. Then user can
> > use keyctl to remove swsusp-kmk key from root's keyring.
> > 
> > If user does not trigger the initialization by disk_kmk file after
> > swsusp-kmk be loaded to kernel. Then the snapshot key will be
> > initialled when hibernation be triggered.
> > 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Pavel Machek 
> > Cc: Chen Yu 
> > Cc: Oliver Neukum 
> > Cc: Ryan Chen 
> > Cc: David Howells 
> > Cc: Giovanni Gherdovich 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
[...snip]
> > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> > index abef759de7c8..18d13cbf0591 100644
> > --- a/kernel/power/hibernate.c
> > +++ b/kernel/power/hibernate.c
> > @@ -1034,6 +1034,39 @@ static ssize_t disk_store(struct kobject *kobj, 
> > struct kobj_attribute *attr,
> >  
> >  power_attr(disk);
> >  
> > +#ifdef CONFIG_HIBERNATION_ENC_AUTH
> > +static ssize_t disk_kmk_show(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > +char *buf)
> > +{
> > +   if (snapshot_key_initialized())
> > +   return sprintf(buf, "initialized\n");
> > +   else
> > +   return sprintf(buf, "uninitialized\n");
> > +}
> > +
> > +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> > *attr,
> > + const char *buf, size_t n)
> > +{
> Does kmk mean kernel master key? It might looks unclear from first glance,
> how about disk_genkey_store()?

Yes, it's the kernel maskter key for disk (hibernate).

The sysfs interfaces is used to load the master key from keyring, then
kernel parses the encrypted key or user defined key to grab the plaintext
key. So sysfs triggered the initial process of the master key.

Even user space didn't trigger the process through sysfs, kernel will
still runs the initial process when hibernation be triggered. Then
kernel uses the master key to derive encrypte key and authenticate key. 

I prefer to keep the name of sysfs and the function name. 

> > +   int error = 0;
> > +   char *p;
> > +   int len;
> > +
> > +   if (!capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> > +
> > +   p = memchr(buf, '\n', n);
> > +   len = p ? p - buf : n;
> > +   if (strncmp(buf, "1", len))
> > +   return -EINVAL;
> Why user is not allowed to disable(remove) it by
> echo 0 ?

Similar with evm, this sysfs interface gives user space a chance
to ask kernel to initial master key. Once the master key be
initialled and loaded, kernel doesn't want the key to be removed
because the key is unsealed by TPM. The PCRs may already capped
then there have no other master key can be unsealed and enrolled.

So, I prefer that do not give user space the function to
remove an enrolled master key. Once the master key be loaded,
kernel will use the key to encrypt snapshot image.   

> > +
> > +   error = snapshot_key_init();
> > +
> > +   return error ? error : n;
> > +}
> > +
> > +power_attr(disk_kmk);
> > +#endif /* !CONFIG_HIBERNATION_ENC_AUTH */
[...snip]
> > diff --git a/kernel/power/snapshot_key.c b/kernel/power/snapshot_key.c
> > new file mode 100644
> > index 

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Randy,

On Wed, Sep 12, 2018 at 09:27:27AM -0700, Randy Dunlap wrote:
> Hi,
> 
> On 9/12/18 7:23 AM, Lee, Chun-Yi wrote:
> > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> > index 3a6c2f87699e..7c5c30149dbc 100644
> > --- a/kernel/power/Kconfig
> > +++ b/kernel/power/Kconfig
> > @@ -76,6 +76,20 @@ config HIBERNATION
> >  
> >   For more information take a look at 
> > .
> >  
> > +config HIBERNATION_ENC_AUTH
> > +   bool "Hibernation encryption and authentication"
> > +   depends on HIBERNATION
> > +   depends on TRUSTED_KEYS
> > +   select CRYPTO_AES
> > +   select CRYPTO_HMAC
> > +   select CRYPTO_SHA512
> > +   help
> > + This option will encrypt and authenticate the memory snapshot image
> > + of hibernation. It prevents that the snapshot image be arbitrary
> 
>arbitrarily
> 
> > + modified. User can use TPMs trusted key or user defined key as the
> 
>   The user
> orA user can use the TPM's trusted key
>

Thanks for your review! I will update it in next version.

Joey Lee 

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[joeyli]

Hi Randy,

On Wed, Sep 12, 2018 at 09:27:27AM -0700, Randy Dunlap wrote:
> Hi,
> 
> On 9/12/18 7:23 AM, Lee, Chun-Yi wrote:
> > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> > index 3a6c2f87699e..7c5c30149dbc 100644
> > --- a/kernel/power/Kconfig
> > +++ b/kernel/power/Kconfig
> > @@ -76,6 +76,20 @@ config HIBERNATION
> >  
> >   For more information take a look at 
> > .
> >  
> > +config HIBERNATION_ENC_AUTH
> > +   bool "Hibernation encryption and authentication"
> > +   depends on HIBERNATION
> > +   depends on TRUSTED_KEYS
> > +   select CRYPTO_AES
> > +   select CRYPTO_HMAC
> > +   select CRYPTO_SHA512
> > +   help
> > + This option will encrypt and authenticate the memory snapshot image
> > + of hibernation. It prevents that the snapshot image be arbitrary
> 
>arbitrarily
> 
> > + modified. User can use TPMs trusted key or user defined key as the
> 
>   The user
> orA user can use the TPM's trusted key
>

Thanks for your review! I will update it in next version.

Joey Lee 

Re: [PATCH 5/5] PM / hibernate: An option to request that snapshot image must be authenticated

[joeyli]

Hi Randy, 

On Wed, Sep 12, 2018 at 09:24:38AM -0700, Randy Dunlap wrote:
> Hi,
> 
> On 9/12/18 7:23 AM, Lee, Chun-Yi wrote:
> > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> > index 7c5c30149dbc..3c998fd6dc4c 100644
> > --- a/kernel/power/Kconfig
> > +++ b/kernel/power/Kconfig
> > @@ -90,6 +90,17 @@ config HIBERNATION_ENC_AUTH
> >   master key of hibernation. The TPM trusted key depends on TPM. The
> >   security of user defined key relies on user space.
> >  
> > +config HIBERNATION_ENC_AUTH_FORCE
> > +   bool "Require hibernate snapshot image to be validly signed"
> > +   depends on HIBERNATION_ENC_AUTH
> > +   help
> > + This option will prevent that a snapshot image without (valid)
> > + signature be restored. Without this option, a unauthenticated
> 
> an
> 
> > + snapshot image can be restored but the restored kernel will be
> > + tainted. Which also means that the hibernation can be triggered
> 
> s/Which/This/
> 
> or like this:
> tainted, which also
>

Thanks for your review and suggestion! I will update the description in
next version.

Regards
Joey Lee

Re: [PATCH 5/5] PM / hibernate: An option to request that snapshot image must be authenticated

[joeyli]

Hi Randy, 

On Wed, Sep 12, 2018 at 09:24:38AM -0700, Randy Dunlap wrote:
> Hi,
> 
> On 9/12/18 7:23 AM, Lee, Chun-Yi wrote:
> > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> > index 7c5c30149dbc..3c998fd6dc4c 100644
> > --- a/kernel/power/Kconfig
> > +++ b/kernel/power/Kconfig
> > @@ -90,6 +90,17 @@ config HIBERNATION_ENC_AUTH
> >   master key of hibernation. The TPM trusted key depends on TPM. The
> >   security of user defined key relies on user space.
> >  
> > +config HIBERNATION_ENC_AUTH_FORCE
> > +   bool "Require hibernate snapshot image to be validly signed"
> > +   depends on HIBERNATION_ENC_AUTH
> > +   help
> > + This option will prevent that a snapshot image without (valid)
> > + signature be restored. Without this option, a unauthenticated
> 
> an
> 
> > + snapshot image can be restored but the restored kernel will be
> > + tainted. Which also means that the hibernation can be triggered
> 
> s/Which/This/
> 
> or like this:
> tainted, which also
>

Thanks for your review and suggestion! I will update the description in
next version.

Regards
Joey Lee

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Fri, Aug 10, 2018 at 08:58:37AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 10, 2018 at 05:25:01PM +0800, joeyli wrote:
> > On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> > ...
[...snip]
> > hm... I have another question that it may not relates to this issue. I
> > was tracing the code path of PCI hot-remove/hotplug. Base on spec, looks
> > that the RST# should be asserted when hot-remove. And the memory decode
> > bit must be set to zero after RST# be asserted. But I didn't see that
> > any kernel PCI/ACPI code set RST#. The only possible code to set RST# is
> > in POWER architecture. Do you know who assert the RST# when hot-remove?
> 
> RST# is a conventional PCI signal (not a PCIe signal).  In any case, I
> would expect signals like that to be handled by hardware, not by
> software.  What section of the spec are you looking at?  I wouldn't

In PCI Hot-Plug Spec v1.1

2.2.1 Hot Removal
The Hot-Plug System Driver uses the Hot-Plug Controller to do the following:
a) Assert RST# to the slot and isolate the slot from the rest of the bus, in
   either order.
b) Power down the slot.
c) Change the optional slot-state indicator, as defined in Section 3.1.1, to 
show
   that the slot is off.

In the above description, it said that "Hot-Plug System Driver" should done
the job. So I was think that kernel driver must asserts RST#, but I didn't
find that in kernel code.

Then, in PCI Local Bus spec v2.2, it mentions:

Table 6-1: Command Register Bits
Bit LocationDescription
0   ...State after RST# is 0.
1   ...State after RST# is 0.

So, after hot-remove the RST# must be asserted and the IO/memory
decode bit should also be set to zero.

I was tracing the kerenl hot-remove code for RST# because I
want to make sure that kernel didn't change the RST# state from
firmware.

> expect any requirements for doing things to a device when the device
> is being hot-removed, since the device may already be inaccessible,
> e.g., physically unreachable.

I see! It makes sense.

But I still confused about the "Hot-Plug System Driver" wording in
PCI Hot-Plug Spec. The "Hot-Plug System Driver " means a kernel
driver?

> 
> On a hot-*add*, there would of course be requirements about how the
> device powers up and comes out of reset.  For native drivers like
> pciehp/shpcpd/etc, there are often ways for software to control power
> to the slot, e.g., the "Power Controller Control" bit in the PCIe Slot
> Control register.
> 
> For ACPI-mediated hotplug (as in your situation), the actual hardware
> details are handled by the firmware and all the OS sees are things
> like ACPI Notify events and it uses methods like _STA and other things
> mentioned in ACPI v6.2, sec 6.3.
> 
> > > What are the chances of getting a firmware fix?  Has this firmware
> > > already shipped to customers?
> > 
> > The good news is that the machine has not shipped yet. As I know
> > that manufacturer is also finding the root cause for why firmware
> > enabled memory decode bit and also set the wrong addresses.
> 
> I don't think it's necessarily a problem that firmware enables the
> IOAPIC.  This is ACPI-mediated hotplug and it looks like it adds CPUs,
> memory, and I/O.  I wouldn't be surprised if the firmware has to make
> the IOAPIC operational to make some parts of the hot-add work.
> 
> The address conflict is the real problem.

Thanks for your explanation. It's really useful to me.

Thanks a lot!
Joey Lee

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Fri, Aug 10, 2018 at 08:58:37AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 10, 2018 at 05:25:01PM +0800, joeyli wrote:
> > On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> > ...
[...snip]
> > hm... I have another question that it may not relates to this issue. I
> > was tracing the code path of PCI hot-remove/hotplug. Base on spec, looks
> > that the RST# should be asserted when hot-remove. And the memory decode
> > bit must be set to zero after RST# be asserted. But I didn't see that
> > any kernel PCI/ACPI code set RST#. The only possible code to set RST# is
> > in POWER architecture. Do you know who assert the RST# when hot-remove?
> 
> RST# is a conventional PCI signal (not a PCIe signal).  In any case, I
> would expect signals like that to be handled by hardware, not by
> software.  What section of the spec are you looking at?  I wouldn't

In PCI Hot-Plug Spec v1.1

2.2.1 Hot Removal
The Hot-Plug System Driver uses the Hot-Plug Controller to do the following:
a) Assert RST# to the slot and isolate the slot from the rest of the bus, in
   either order.
b) Power down the slot.
c) Change the optional slot-state indicator, as defined in Section 3.1.1, to 
show
   that the slot is off.

In the above description, it said that "Hot-Plug System Driver" should done
the job. So I was think that kernel driver must asserts RST#, but I didn't
find that in kernel code.

Then, in PCI Local Bus spec v2.2, it mentions:

Table 6-1: Command Register Bits
Bit LocationDescription
0   ...State after RST# is 0.
1   ...State after RST# is 0.

So, after hot-remove the RST# must be asserted and the IO/memory
decode bit should also be set to zero.

I was tracing the kerenl hot-remove code for RST# because I
want to make sure that kernel didn't change the RST# state from
firmware.

> expect any requirements for doing things to a device when the device
> is being hot-removed, since the device may already be inaccessible,
> e.g., physically unreachable.

I see! It makes sense.

But I still confused about the "Hot-Plug System Driver" wording in
PCI Hot-Plug Spec. The "Hot-Plug System Driver " means a kernel
driver?

> 
> On a hot-*add*, there would of course be requirements about how the
> device powers up and comes out of reset.  For native drivers like
> pciehp/shpcpd/etc, there are often ways for software to control power
> to the slot, e.g., the "Power Controller Control" bit in the PCIe Slot
> Control register.
> 
> For ACPI-mediated hotplug (as in your situation), the actual hardware
> details are handled by the firmware and all the OS sees are things
> like ACPI Notify events and it uses methods like _STA and other things
> mentioned in ACPI v6.2, sec 6.3.
> 
> > > What are the chances of getting a firmware fix?  Has this firmware
> > > already shipped to customers?
> > 
> > The good news is that the machine has not shipped yet. As I know
> > that manufacturer is also finding the root cause for why firmware
> > enabled memory decode bit and also set the wrong addresses.
> 
> I don't think it's necessarily a problem that firmware enables the
> IOAPIC.  This is ACPI-mediated hotplug and it looks like it adds CPUs,
> memory, and I/O.  I wouldn't be surprised if the firmware has to make
> the IOAPIC operational to make some parts of the hot-add work.
> 
> The address conflict is the real problem.

Thanks for your explanation. It's really useful to me.

Thanks a lot!
Joey Lee

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 08, 2018 at 11:53:18PM +0800, joeyli wrote:
> > Hi Bjorn,
> > 
> > First, thanks for your review!
> > 
> > On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > > > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > > > with the resource of a children bus when the PCI host bus be hotplug.
> > > > 
> > > > [ 3182.243325] PCI host bridge to bus 0001:40
> > > > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff 
> > > > window]
> > > > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > > > 0xdc00-0xebff window]
> > > > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > > > 0x2124-0x2125 window]
> > > > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > > > ...
> > > > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > > > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > > > ...
> > > > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > > > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 
> > > > 0xdc00-0xdc7f]
> > > > ...
> > > > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: 
> > > > address conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > > > 
> > > > The bus topology:
> > > > 
> > > >  +-[0001:40]-+-02.0-[41]--
> > > >  |   +-03.0-[41]--
> > > >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.1  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.2  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |\-00.3  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D Map/VTd_Misc/System Management
> > > >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO Hot Plug
> > > >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO RAS/Control Status/Global Errors
> > > >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D I/O APIC
> > > > 
> > > > This problem causes that the NIC behine the child bus was not available
> > > > after PCI host bridge hotpluged.
> > > > 
> > > > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > > > the priority of children bus's resources are higher than any other 
> > > > devices.
> > > > So this conflict can not be handled by the reassigning logic of kernel.
> > 
> > Sorry for my description is not clear. The "priority" is for resources
> > clamining, not for the address decoding.
> > 
> > > I don't understand this paragraph.  AFAIK, if two devices on a bus
> > > both decode the same address, as the IOAPIC and the bridge do here,
> > > the only real "priority" in PCI would be subtractive decode.  But I
> > > don't think that applies here since the bridge is using a positive
> > > decode window.
> > 
> > Sorry for I didn't understand... How could you know the bridge doesn't
> > apply subtractive decode?
> 
> A subtractive decode bridge forwards anything appearing on its primary
> bus to its secondary bus.  In conventional PCI, it only does this if
> no other agent on the primary bus asserts DEVSEL# (PCI r3.0, sec
> 3.6.1).  In PCIe, the primary "bus" is a link and there's only one
> device on it, so a subtractive decode bridge could forward anything it
> sees.  If the subtractive decode bridge is part of a multi-function
> device, I assume that multi-function device would have to determine
> internally whether the subtractive decode bridge or another function
> should claim the transaction.
> 
> Either way, a subtractive decode bridge can forward anything that
> appears on its primary bus, so a subtractive decode window effectively
> contains everything the upstream bridge passes down.  In this case you
> have:
> 
>   pci_b

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 08, 2018 at 11:53:18PM +0800, joeyli wrote:
> > Hi Bjorn,
> > 
> > First, thanks for your review!
> > 
> > On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > > > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > > > with the resource of a children bus when the PCI host bus be hotplug.
> > > > 
> > > > [ 3182.243325] PCI host bridge to bus 0001:40
> > > > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff 
> > > > window]
> > > > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > > > 0xdc00-0xebff window]
> > > > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > > > 0x2124-0x2125 window]
> > > > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > > > ...
> > > > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > > > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > > > ...
> > > > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > > > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 
> > > > 0xdc00-0xdc7f]
> > > > ...
> > > > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: 
> > > > address conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > > > 
> > > > The bus topology:
> > > > 
> > > >  +-[0001:40]-+-02.0-[41]--
> > > >  |   +-03.0-[41]--
> > > >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.1  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.2  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |\-00.3  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D Map/VTd_Misc/System Management
> > > >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO Hot Plug
> > > >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO RAS/Control Status/Global Errors
> > > >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D I/O APIC
> > > > 
> > > > This problem causes that the NIC behine the child bus was not available
> > > > after PCI host bridge hotpluged.
> > > > 
> > > > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > > > the priority of children bus's resources are higher than any other 
> > > > devices.
> > > > So this conflict can not be handled by the reassigning logic of kernel.
> > 
> > Sorry for my description is not clear. The "priority" is for resources
> > clamining, not for the address decoding.
> > 
> > > I don't understand this paragraph.  AFAIK, if two devices on a bus
> > > both decode the same address, as the IOAPIC and the bridge do here,
> > > the only real "priority" in PCI would be subtractive decode.  But I
> > > don't think that applies here since the bridge is using a positive
> > > decode window.
> > 
> > Sorry for I didn't understand... How could you know the bridge doesn't
> > apply subtractive decode?
> 
> A subtractive decode bridge forwards anything appearing on its primary
> bus to its secondary bus.  In conventional PCI, it only does this if
> no other agent on the primary bus asserts DEVSEL# (PCI r3.0, sec
> 3.6.1).  In PCIe, the primary "bus" is a link and there's only one
> device on it, so a subtractive decode bridge could forward anything it
> sees.  If the subtractive decode bridge is part of a multi-function
> device, I assume that multi-function device would have to determine
> internally whether the subtractive decode bridge or another function
> should claim the transaction.
> 
> Either way, a subtractive decode bridge can forward anything that
> appears on its primary bus, so a subtractive decode window effectively
> contains everything the upstream bridge passes down.  In this case you
> have:
> 
>   pci_b

Re: [PATCH v2] platform/x86: acer-wmi: refactor function has_cap

[joeyli]

Hi Gustavo, 

Sorry for my delay!

On Mon, Aug 06, 2018 at 03:38:32PM -0500, Gustavo A. R. Silva wrote:
> Refactor function has_cap in order to avoid returning integer
> values, when instead it should return booleans.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Thanks for your patch and also thank Andy and Joe's help. 

Please feel free to add:

Reviewed-by: "Lee, Chun-Yi"  

Joey Lee

> ---
> Changes in v2:
>   Remove parentheses and unnecessary code. Thank you all for
>   the feedback!
> 
>  drivers/platform/x86/acer-wmi.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 8952173..3294bb2 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -672,10 +672,7 @@ static void __init find_quirks(void)
>  
>  static bool has_cap(u32 cap)
>  {
> - if ((interface->capability & cap) != 0)
> - return 1;
> -
> - return 0;
> + return interface->capability & cap;
>  }
>  
>  /*
> -- 
> 2.7.4
> 

Re: [PATCH v2] platform/x86: acer-wmi: refactor function has_cap

[joeyli]

Hi Gustavo, 

Sorry for my delay!

On Mon, Aug 06, 2018 at 03:38:32PM -0500, Gustavo A. R. Silva wrote:
> Refactor function has_cap in order to avoid returning integer
> values, when instead it should return booleans.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Thanks for your patch and also thank Andy and Joe's help. 

Please feel free to add:

Reviewed-by: "Lee, Chun-Yi"  

Joey Lee

> ---
> Changes in v2:
>   Remove parentheses and unnecessary code. Thank you all for
>   the feedback!
> 
>  drivers/platform/x86/acer-wmi.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 8952173..3294bb2 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -672,10 +672,7 @@ static void __init find_quirks(void)
>  
>  static bool has_cap(u32 cap)
>  {
> - if ((interface->capability & cap) != 0)
> - return 1;
> -
> - return 0;
> + return interface->capability & cap;
>  }
>  
>  /*
> -- 
> 2.7.4
> 

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

Hi Bjorn,

First, thanks for your review!

On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > with the resource of a children bus when the PCI host bus be hotplug.
> > 
> > [ 3182.243325] PCI host bridge to bus 0001:40
> > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff window]
> > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > 0xdc00-0xebff window]
> > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > 0x2124-0x2125 window]
> > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > ...
> > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > ...
> > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 0xdc00-0xdc7f]
> > ...
> > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: address 
> > conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > 
> > The bus topology:
> > 
> >  +-[0001:40]-+-02.0-[41]--
> >  |   +-03.0-[41]--
> >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |+-00.1  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |+-00.2  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |\-00.3  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D Map/VTd_Misc/System Management
> >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D IIO Hot Plug
> >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D IIO RAS/Control Status/Global Errors
> >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D I/O APIC
> > 
> > This problem causes that the NIC behine the child bus was not available
> > after PCI host bridge hotpluged.
> > 
> > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > the priority of children bus's resources are higher than any other devices.
> > So this conflict can not be handled by the reassigning logic of kernel.

Sorry for my description is not clear. The "priority" is for resources
clamining, not for the address decoding.

> 
> I don't understand this paragraph.  AFAIK, if two devices on a bus
> both decode the same address, as the IOAPIC and the bridge do here,
> the only real "priority" in PCI would be subtractive decode.  But I
> don't think that applies here since the bridge is using a positive
> decode window.
>

Sorry for I didn't understand... How could you know the bridge doesn't
apply subtractive decode?

> I would expect that a read to the [mem 0xdc00-0xdc000fff] range
> would potentially receive two read completions, which would cause an
> Unexpected Completion error.
>

Thanks for your information. The I350 NIC doesn't work after hotplug.
So it may causes by Unexpected Completion error as you mentioned.
 
> Maybe you mean that we don't want to change the IOAPIC resources, but
> it's OK if we move the bridge window, so in that sense, the IOAPIC is
> "higher priority" than the bridge window?  This is the reverse of what
> your paragraph seems to say.
>

Yes, this is what I mean. Sorry for my paragraph causes confusing. 

The memory decoder bit in the command register of 0001:40:05.4 IOAPIC
is raised by firmware after hotplug. So kernel treats it as a
_firmware enabled_ IOAPIC. Because kernel don't want to change the IOAPIC
resources, so my patch try to claim the IOAPIC resources before all
bridges. It can workaround the hotplug problem on issue machine.

But, actually I am not sure that this hacking makes sense. And, I also
don't know why the memory decoder bit is raised by firmware when hotplug.
Maybe this is a firmware problem.
 
> > This patch claims the resources of firmware enabled IOAPIC before
> > children bus. Then kernel gets a chance to reassign the resources of
> > children bus to avoid the conflict.
> 
> Can you open a report at https://bugzilla.kernel.org, attach the
> before and after dmesg logs, and include the URL in the commit log?
>

OK, I have filed a bug on kernel bugzilla and also attached dmesg
log:
https://bugzilla.kernel.org/show_bug.cgi?id=200765

Thanks a lot!
Joey Lee

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

Hi Bjorn,

First, thanks for your review!

On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > with the resource of a children bus when the PCI host bus be hotplug.
> > 
> > [ 3182.243325] PCI host bridge to bus 0001:40
> > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff window]
> > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > 0xdc00-0xebff window]
> > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > 0x2124-0x2125 window]
> > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > ...
> > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > ...
> > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 0xdc00-0xdc7f]
> > ...
> > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: address 
> > conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > 
> > The bus topology:
> > 
> >  +-[0001:40]-+-02.0-[41]--
> >  |   +-03.0-[41]--
> >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |+-00.1  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |+-00.2  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   |\-00.3  Intel Corporation I350 Gigabit Network 
> > Connection
> >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D Map/VTd_Misc/System Management
> >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D IIO Hot Plug
> >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D IIO RAS/Control Status/Global Errors
> >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > v4/Xeon D I/O APIC
> > 
> > This problem causes that the NIC behine the child bus was not available
> > after PCI host bridge hotpluged.
> > 
> > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > the priority of children bus's resources are higher than any other devices.
> > So this conflict can not be handled by the reassigning logic of kernel.

Sorry for my description is not clear. The "priority" is for resources
clamining, not for the address decoding.

> 
> I don't understand this paragraph.  AFAIK, if two devices on a bus
> both decode the same address, as the IOAPIC and the bridge do here,
> the only real "priority" in PCI would be subtractive decode.  But I
> don't think that applies here since the bridge is using a positive
> decode window.
>

Sorry for I didn't understand... How could you know the bridge doesn't
apply subtractive decode?

> I would expect that a read to the [mem 0xdc00-0xdc000fff] range
> would potentially receive two read completions, which would cause an
> Unexpected Completion error.
>

Thanks for your information. The I350 NIC doesn't work after hotplug.
So it may causes by Unexpected Completion error as you mentioned.
 
> Maybe you mean that we don't want to change the IOAPIC resources, but
> it's OK if we move the bridge window, so in that sense, the IOAPIC is
> "higher priority" than the bridge window?  This is the reverse of what
> your paragraph seems to say.
>

Yes, this is what I mean. Sorry for my paragraph causes confusing. 

The memory decoder bit in the command register of 0001:40:05.4 IOAPIC
is raised by firmware after hotplug. So kernel treats it as a
_firmware enabled_ IOAPIC. Because kernel don't want to change the IOAPIC
resources, so my patch try to claim the IOAPIC resources before all
bridges. It can workaround the hotplug problem on issue machine.

But, actually I am not sure that this hacking makes sense. And, I also
don't know why the memory decoder bit is raised by firmware when hotplug.
Maybe this is a firmware problem.
 
> > This patch claims the resources of firmware enabled IOAPIC before
> > children bus. Then kernel gets a chance to reassign the resources of
> > children bus to avoid the conflict.
> 
> Can you open a report at https://bugzilla.kernel.org, attach the
> before and after dmesg logs, and include the URL in the commit log?
>

OK, I have filed a bug on kernel bugzilla and also attached dmesg
log:
https://bugzilla.kernel.org/show_bug.cgi?id=200765

Thanks a lot!
Joey Lee

Re: [PATCH 0/6][RFC] Add EFI secure key to key retention service

[joeyli]

Hi James,

On Sun, Aug 05, 2018 at 10:47:26AM -0700, James Bottomley wrote:
> On Sun, 2018-08-05 at 09:25 +0200, Ard Biesheuvel wrote:
> > Hello Chun,yi,
> > 
> > On 5 August 2018 at 05:21, Lee, Chun-Yi 
> > wrote:
> > > When secure boot is enabled, only signed EFI binary can access
> > > EFI boot service variable before ExitBootService. Which means that
> > > the EFI boot service variable is secure.
> > > 
> > 
> > No it, isn't, and this is a very dangerous assumption to make.
> > 
> > 'Secure' means different things to different people. 'Secure boot' is
> > a misnomer, since it is too vague: it should be called 'authenticated
> > boot', and the catch is that authentication using public-key crypto
> > does not involve secrets at all.
> 
> Hang on, let's not throw the baby out with the bathwater here.
> 
> The design of "secure boot" is to create a boot time environment where
> only trusted code may execute.  We rely on this trust guarantee when we
> pivot from the EFI to the MoK root of trust in shim.
> 
> The reason we in Linux trust this guarantee is that it pertains to the
> boot environment only, so any violation would allow Windows boot to be
> compromised as well and we trust Microsoft's Business interests in
> securing windows far enough to think this would be dealt with very
> severely and it's an outcome the ODMs (who also add secure boot keys)
> are worried enough about to be very careful.
> 
> The rub (and this is where I'm agreeing with Ard) is that any use case
> we come up with where a violation wouldn't cause a problem in windows
> is a use case where we cannot rely on the guarantee because Microsoft
> no longer has a strong business interest in policing it.  This, for
> instance, is why we don't populate the Linux trusted keyrings with the
> secure boot keys (we may trust them in the boot environment where
> compromise would be shared with windows but we can't trust them in the
> Linux OS environment where it wouldn't).  So this means we have to be
> very careful coming up with uses for secure boot that aren't strictly
> rooted in the guarantee as enforced by the business interests of
> Microsoft and the ODMs.
>

Thank you for providing the view point from Microsoft bussiness ineterests.
I agreed with you. Honestly I didn't think this point before.
 
> >  The UEFI variable store was not designed with confidentiality in
> > mind, and assuming [given the reputation of EFI on the implementation
> > side] that you can use it to keep secrets is rather unwise imho.
> 
> Agree completely here: Microsoft doesn't use UEFI variables for
> confidentiality, so we shouldn't either.  If you want confidentiality,
> use a TPM (like Microsoft does for the bitlocker key).
>

OK~~ Then I will use TPM trusted key + encrypted key in hibernation
encryption/authentication.

Thanks for James and Ard's comments.

Joey Lee 
--
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 0/6][RFC] Add EFI secure key to key retention service

[joeyli]

On Sun, Aug 05, 2018 at 09:25:56AM +0200, Ard Biesheuvel wrote:
> Hello Chun,yi,
> 
> On 5 August 2018 at 05:21, Lee, Chun-Yi  wrote:
> > When secure boot is enabled, only signed EFI binary can access
> > EFI boot service variable before ExitBootService. Which means that
> > the EFI boot service variable is secure.
> >
> 
> No it, isn't, and this is a very dangerous assumption to make.
> 
> 'Secure' means different things to different people. 'Secure boot' is
> a misnomer, since it is too vague: it should be called 'authenticated
> boot', and the catch is that authentication using public-key crypto
> does not involve secrets at all. The UEFI variable store was not
> designed with confidentiality in mind, and assuming [given the
> reputation of EFI on the implementation side] that you can use it to
> keep secrets is rather unwise imho.
>

I agreed with you. Especially I can't refute the part of EFI
implementation, manufacturers can not be fully trusted. 

I am thinking a case... Some machines provide setup mode. If user
earses all manufacturer's reloaded keys and only enrolls their own
key. Which means that user fully controls the authentication
environment. Then the EFI boot service varible can be trusted by
the user. But this case is too strict for normal user.

Thanks for your review and comments. I will think more about your
suggestions.

Joey Lee  
--
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 1/6] x86/KASLR: make getting random long number function public

[joeyli]

Hi Ard,

On Sun, Aug 05, 2018 at 10:16:03AM +0200, Ard Biesheuvel wrote:
> On 5 August 2018 at 05:21, Lee, Chun-Yi  wrote:
> > Separating the functions for getting random long number from KASLR
> > to x86 library, then it can be used to generate random long for
> > EFI root key.
> >
> > Cc: Kees Cook 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Pavel Machek 
> > Cc: Chen Yu 
> > Cc: Oliver Neukum 
> > Cc: Ryan Chen 
> > Cc: Ard Biesheuvel 
> > Cc: David Howells 
> > Cc: Mimi Zohar 
> > Signed-off-by: "Lee, Chun-Yi" 
> 
> Not my call to make perhaps, but i'm nacking it anyway.
> 
> Playing games with counters and other low entropy inputs may have been
> acceptable for kaslr on x86 when it was first introduced, but using it
> to generate symmetric keys is really out of the question.
> 
> On modern x86, i suppose rdrand is a given, and these days we have
> EFI_RNG_PROTOCOL as well (and an open source UEFI driver for ChasoKey,
> btw - perhaps we should try and get MS to sign that?), although I'm
> not sure whether any x86 support this out of the box now.
> 
> BTW using low entropy inputs on top of rdrand or EFI_RNG_PROTOCOL is
> fine, if you're paranoid, but if you have neither of those, you should
> really fail the call.
> 

I agreed with your suggestion. I will add EFI_RNG_PROTOCOL and also checking
the existence of RDRAND and EFI_RNG_PROTOCOL.

Thanks for your view.

Joey Lee
 
> > ---
> >  arch/x86/boot/compressed/kaslr.c | 21 -
> >  arch/x86/boot/compressed/misc.c  | 17 ++
> >  arch/x86/boot/compressed/misc.h  |  6 
> >  arch/x86/lib/kaslr.c | 61 ++-
> >  arch/x86/lib/random.c| 68 
> > 
> >  5 files changed, 93 insertions(+), 80 deletions(-)
> >  create mode 100644 arch/x86/lib/random.c
> >
> > diff --git a/arch/x86/boot/compressed/kaslr.c 
> > b/arch/x86/boot/compressed/kaslr.c
> > index b87a7582853d..0f40d2178ebc 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -33,13 +33,11 @@
> >  #include "error.h"
> >  #include "../string.h"
> >
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >
> >  /* Macros used by the included decompressor code below. */
> > @@ -57,25 +55,6 @@ extern unsigned long get_cmd_line_ptr(void);
> >  /* Used by PAGE_KERN* macros: */
> >  pteval_t __default_kernel_pte_mask __read_mostly = ~0;
> >
> > -/* Simplified build-specific string for starting entropy. */
> > -static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
> > -   LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
> > -
> > -static unsigned long rotate_xor(unsigned long hash, const void *area,
> > -   size_t size)
> > -{
> > -   size_t i;
> > -   unsigned long *ptr = (unsigned long *)area;
> > -
> > -   for (i = 0; i < size / sizeof(hash); i++) {
> > -   /* Rotate by odd number of bits and XOR. */
> > -   hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
> > -   hash ^= ptr[i];
> > -   }
> > -
> > -   return hash;
> > -}
> > -
> >  /* Attempt to create a simple but unpredictable starting entropy. */
> >  static unsigned long get_boot_seed(void)
> >  {
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index 8dd1d5ccae58..eb0ab9cad4e4 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -426,3 +426,20 @@ void fortify_panic(const char *name)
> >  {
> > error("detected buffer overflow");
> >  }
> > +
> > +#if CONFIG_RANDOMIZE_BASE
> > +unsigned long rotate_xor(unsigned long hash, const void *area,
> > +   size_t size)
> > +{
> > +   size_t i;
> > +   unsigned long *ptr = (unsigned long *)area;
> > +
> > +   for (i = 0; i < size / sizeof(hash); i++) {
> > +   /* Rotate by odd number of bits and XOR. */
> > +   hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
> > +   hash ^= ptr[i];
> > +   }
> > +
> > +   return hash;
> > +}
> > +#endif
> > diff --git a/arch/x86/boot/compressed/misc.h 
> > b/arch/x86/boot/compressed/misc.h
> > index a423bdb42686..957f327ad83c 100644
> > --- a/arch/x86/boot/compressed/misc.h
> > +++ b/arch/x86/boot/compressed/misc.h
> > @@ -70,6 +70,8 @@ int cmdline_find_option_bool(const char *option);
> >
> >
> >  #if CONFIG_RANDOMIZE_BASE
> > +#include 
> > +#include 
> >  /* kaslr.c */
> >  void choose_random_location(unsigned long input,
> > unsigned long input_size,
> > @@ -78,6 +80,10 @@ void choose_random_location(unsigned long input,
> > unsigned long *virt_addr);
> >  /* cpuflags.c */
> >  bool has_cpuflag(int flag);
> > +/* Simplified 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> > Hi Yu Chen, 
> > 
> > Sorry for my delay...
> > 
> > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
[...snip]
> > > > Why the cryption code must be indepent of snapshot code?
> > > >
> > > Modules can be easier to be maintained and customized/improved in the 
> > > future IMO..
> > 
> > hm... currently I didn't see apparent benefit on this...
> > 
> > About modularization, is it possible to separate the key handler code
> > from crypto_hibernation.c? Otherwise the snapshot signature needs
> > to depend on encrypt function.
> > 
> I understand.
> It seems that we can reuse crypto_data() for the signature logic.
> For example, add one parameter for crypto_data(..., crypto_mode)
> the crypto_mode is a combination of 
> ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
> and can be controled by sysfs. If SIGNATURE_START is enabled, the 
> crypto_data()
> invokes crypto_shash_update() to get "hmac(sha512)" hash, and if SIGNATURE_END
> is enabled, crypto_shash_final() stores the final result in global buffer

I agree that the swsusp_prepare and hmac-hash codes can be extract to
crypto_hibernation.  

> struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
> passed to the restore kernel, the same as the salt. Besides,

The salt is stored in the swsusp_header and put in swap. What I want
is that the signature of snapshot should be keep in the snapshot header
as my original design in patch. The benefit is that the snapshot with
signature can be stored to any place but not just swap. The user space
can take snapshot image with signature to anywhere.

> the swsusp_prepare_hash() in your code could be moved into
> init_crypto_helper(), thus the signature key could also reuse
> the same key passed from user space or via get_efi_secret_key().
> In this way, the change in snapshot.c is minimal and the crypto
> facilities could be maintained in one file.

I agree. But as I mentioned in that mail, the key handler codes
in hibernation_crypto() should be extract to another C file to avoid
the logic is mixed with the crypto code. The benefit is that we can
add more key sources like encrypted key or EFI key in the future. 

> > > > > 2. There's no need to traverse the snapshot image twice, if the
> > > > >image is large(there's requirement on servers now) we can
> > > > >simplyly do the encryption before the disk IO, and this is
> > > > >why PATCH[2/3] looks like this.
> > > > 
> > > > If the encryption solution is only for block device, then the uswsusp
> > > > interface must be locked-down when kernel is in locked mode:
> > > > 
> > > > uswsusp: Disable when the kernel is locked down
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > > > 
> > > > I still suggest to keep the solution to direct encript the snapshot
> > > > image for uswsusp because the snapshot can be encrypted by kernel
> > > > before user space get it.
> > > > 
> > > > I mean that if the uswsusp be used, then kernel direct encrypts the
> > > > snapshot image, otherwise kernel encrypts pages before block io.
> > > > 
> > > I did not quite get the point, if the kernel has been locked down,
> > > then the uswsusp is disabled, why the kernel encrypts the snapshot
> > > for uswsusp?
> > 
> > There have some functions be locked-down because there have no
> > appropriate mechanisms to check the integrity of writing data. If
> > the snapshot image can be encrypted and authentication, then the
> > uswsusp interface is avaiable for userspace. We do not need to lock
> > it down.
> Ok, I got your point. To be honest, I like your implementation to treat
> the snapshot data seperately except that it might cause small overhead
> when traversing large number of snapshot and make snapshot logic a little
> coupling with crypto logic. Let me send our v2 using the crypto-before-blockio
> for review and maybe change to your solution using the encapsulated APIs in
> crypto_hibernate.c.

Because sometimes I stick on other topics...

If you are urgent for pushing your encryption solution. Please do not
consider too much on signature check. Just complete your patches and push
to kernel mainline. I will follow your result to respin my signature work.

Thanks
Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> > Hi Yu Chen, 
> > 
> > Sorry for my delay...
> > 
> > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
[...snip]
> > > > Why the cryption code must be indepent of snapshot code?
> > > >
> > > Modules can be easier to be maintained and customized/improved in the 
> > > future IMO..
> > 
> > hm... currently I didn't see apparent benefit on this...
> > 
> > About modularization, is it possible to separate the key handler code
> > from crypto_hibernation.c? Otherwise the snapshot signature needs
> > to depend on encrypt function.
> > 
> I understand.
> It seems that we can reuse crypto_data() for the signature logic.
> For example, add one parameter for crypto_data(..., crypto_mode)
> the crypto_mode is a combination of 
> ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
> and can be controled by sysfs. If SIGNATURE_START is enabled, the 
> crypto_data()
> invokes crypto_shash_update() to get "hmac(sha512)" hash, and if SIGNATURE_END
> is enabled, crypto_shash_final() stores the final result in global buffer

I agree that the swsusp_prepare and hmac-hash codes can be extract to
crypto_hibernation.  

> struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
> passed to the restore kernel, the same as the salt. Besides,

The salt is stored in the swsusp_header and put in swap. What I want
is that the signature of snapshot should be keep in the snapshot header
as my original design in patch. The benefit is that the snapshot with
signature can be stored to any place but not just swap. The user space
can take snapshot image with signature to anywhere.

> the swsusp_prepare_hash() in your code could be moved into
> init_crypto_helper(), thus the signature key could also reuse
> the same key passed from user space or via get_efi_secret_key().
> In this way, the change in snapshot.c is minimal and the crypto
> facilities could be maintained in one file.

I agree. But as I mentioned in that mail, the key handler codes
in hibernation_crypto() should be extract to another C file to avoid
the logic is mixed with the crypto code. The benefit is that we can
add more key sources like encrypted key or EFI key in the future. 

> > > > > 2. There's no need to traverse the snapshot image twice, if the
> > > > >image is large(there's requirement on servers now) we can
> > > > >simplyly do the encryption before the disk IO, and this is
> > > > >why PATCH[2/3] looks like this.
> > > > 
> > > > If the encryption solution is only for block device, then the uswsusp
> > > > interface must be locked-down when kernel is in locked mode:
> > > > 
> > > > uswsusp: Disable when the kernel is locked down
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > > > 
> > > > I still suggest to keep the solution to direct encript the snapshot
> > > > image for uswsusp because the snapshot can be encrypted by kernel
> > > > before user space get it.
> > > > 
> > > > I mean that if the uswsusp be used, then kernel direct encrypts the
> > > > snapshot image, otherwise kernel encrypts pages before block io.
> > > > 
> > > I did not quite get the point, if the kernel has been locked down,
> > > then the uswsusp is disabled, why the kernel encrypts the snapshot
> > > for uswsusp?
> > 
> > There have some functions be locked-down because there have no
> > appropriate mechanisms to check the integrity of writing data. If
> > the snapshot image can be encrypted and authentication, then the
> > uswsusp interface is avaiable for userspace. We do not need to lock
> > it down.
> Ok, I got your point. To be honest, I like your implementation to treat
> the snapshot data seperately except that it might cause small overhead
> when traversing large number of snapshot and make snapshot logic a little
> coupling with crypto logic. Let me send our v2 using the crypto-before-blockio
> for review and maybe change to your solution using the encapsulated APIs in
> crypto_hibernate.c.

Because sometimes I stick on other topics...

If you are urgent for pushing your encryption solution. Please do not
consider too much on signature check. Just complete your patches and push
to kernel mainline. I will follow your result to respin my signature work.

Thanks
Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

Hi Yu Chen, 

Sorry for my delay...

On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> Hi Joey Lee,
> On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> > On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > > Hi,
> > > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > > Hi,
> > > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > > Hi Chen Yu,
> > > > > > 
> > > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > > Use the helper functions introduced previously to encrypt
> > > > > > > the page data before they are submitted to the block device.
> > > > > > > Besides, for the case of hibernation compression, the data
> > > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > > for the resume process.
> > > > > > >
> > > > > > 
> > > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > > memory snapshot image. This solution is already shipped with
> > > > > > SLE12 a couple of years:
> > > > > > 
> > > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > > 
> > > > > I did not see image page encryption in above link, if I understand
> > > > 
> > > > PM / hibernate: Generate and verify signature for snapshot image
> > > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > > >
> > > > PM / hibernate: snapshot image encryption
> > > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > > >
> > > > The above patches sign and encrypt the data pages in snapshot image.
> > > > It puts the signature to header.
> > > >
> > > It looks like your signature code can be simplyly added on top of the
> > > solution we proposed here, how about we collaborating on this task?
> > 
> > OK, I will base on your user key solution to respin my signature patches.
> >  
> > > just my 2 cents, 
> > > 1. The cryption code should be indepent of the snapshot code, and
> > >this is why we implement it as a kernel module for that in PATCH[1/3].
> > 
> > Why the cryption code must be indepent of snapshot code?
> >
> Modules can be easier to be maintained and customized/improved in the future 
> IMO..

hm... currently I didn't see apparent benefit on this...

About modularization, is it possible to separate the key handler code
from crypto_hibernation.c? Otherwise the snapshot signature needs
to depend on encrypt function.

> > > 2. There's no need to traverse the snapshot image twice, if the
> > >image is large(there's requirement on servers now) we can
> > >simplyly do the encryption before the disk IO, and this is
> > >why PATCH[2/3] looks like this.
> > 
> > If the encryption solution is only for block device, then the uswsusp
> > interface must be locked-down when kernel is in locked mode:
> > 
> > uswsusp: Disable when the kernel is locked down
> > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > 
> > I still suggest to keep the solution to direct encript the snapshot
> > image for uswsusp because the snapshot can be encrypted by kernel
> > before user space get it.
> > 
> > I mean that if the uswsusp be used, then kernel direct encrypts the
> > snapshot image, otherwise kernel encrypts pages before block io.
> > 
> I did not quite get the point, if the kernel has been locked down,
> then the uswsusp is disabled, why the kernel encrypts the snapshot
> for uswsusp?

There have some functions be locked-down because there have no
appropriate mechanisms to check the integrity of writing data. If
the snapshot image can be encrypted and authentication, then the
uswsusp interface is avaiable for userspace. We do not need to lock
it down.

> > On the other hand, I have a question about asynchronous block io.
> > Please see below...
> > 
> Okay.
> > > > > > > Suggested-by: Rafael J. Wysocki 
> > > > > > > Cc: Rafael J. Wysocki 
> > > > > > > Cc: Pavel Machek 
> > > > > > 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

Hi Yu Chen, 

Sorry for my delay...

On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> Hi Joey Lee,
> On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> > On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > > Hi,
> > > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > > Hi,
> > > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > > Hi Chen Yu,
> > > > > > 
> > > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > > Use the helper functions introduced previously to encrypt
> > > > > > > the page data before they are submitted to the block device.
> > > > > > > Besides, for the case of hibernation compression, the data
> > > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > > for the resume process.
> > > > > > >
> > > > > > 
> > > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > > memory snapshot image. This solution is already shipped with
> > > > > > SLE12 a couple of years:
> > > > > > 
> > > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > > 
> > > > > I did not see image page encryption in above link, if I understand
> > > > 
> > > > PM / hibernate: Generate and verify signature for snapshot image
> > > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > > >
> > > > PM / hibernate: snapshot image encryption
> > > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > > >
> > > > The above patches sign and encrypt the data pages in snapshot image.
> > > > It puts the signature to header.
> > > >
> > > It looks like your signature code can be simplyly added on top of the
> > > solution we proposed here, how about we collaborating on this task?
> > 
> > OK, I will base on your user key solution to respin my signature patches.
> >  
> > > just my 2 cents, 
> > > 1. The cryption code should be indepent of the snapshot code, and
> > >this is why we implement it as a kernel module for that in PATCH[1/3].
> > 
> > Why the cryption code must be indepent of snapshot code?
> >
> Modules can be easier to be maintained and customized/improved in the future 
> IMO..

hm... currently I didn't see apparent benefit on this...

About modularization, is it possible to separate the key handler code
from crypto_hibernation.c? Otherwise the snapshot signature needs
to depend on encrypt function.

> > > 2. There's no need to traverse the snapshot image twice, if the
> > >image is large(there's requirement on servers now) we can
> > >simplyly do the encryption before the disk IO, and this is
> > >why PATCH[2/3] looks like this.
> > 
> > If the encryption solution is only for block device, then the uswsusp
> > interface must be locked-down when kernel is in locked mode:
> > 
> > uswsusp: Disable when the kernel is locked down
> > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > 
> > I still suggest to keep the solution to direct encript the snapshot
> > image for uswsusp because the snapshot can be encrypted by kernel
> > before user space get it.
> > 
> > I mean that if the uswsusp be used, then kernel direct encrypts the
> > snapshot image, otherwise kernel encrypts pages before block io.
> > 
> I did not quite get the point, if the kernel has been locked down,
> then the uswsusp is disabled, why the kernel encrypts the snapshot
> for uswsusp?

There have some functions be locked-down because there have no
appropriate mechanisms to check the integrity of writing data. If
the snapshot image can be encrypted and authentication, then the
uswsusp interface is avaiable for userspace. We do not need to lock
it down.

> > On the other hand, I have a question about asynchronous block io.
> > Please see below...
> > 
> Okay.
> > > > > > > Suggested-by: Rafael J. Wysocki 
> > > > > > > Cc: Rafael J. Wysocki 
> > > > > > > Cc: Pavel Machek 
> > > > > > 

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[joeyli]

Hi Chen Yu, 

On Wed, Jun 20, 2018 at 05:39:37PM +0800, Chen Yu wrote:
> Hi,
> As security becomes more and more important, we add the in-kernel
> encryption support for hibernation.
> 
> This prototype is a trial version to implement the hibernation
> encryption in the kernel, so that the users do not have to rely
> on third-party tools to encrypt the hibernation image. The only
> dependency on user space is that, the user space should provide
> a valid key derived from passphrase to the kernel for image encryption.
> 
> There was a discussion on the mailing list on whether this key should
> be derived in kernel or in user space. And it turns out to be generating
> the key by user space is more acceptable[1]. So this patch set is divided
> into two parts:
> 1. The hibernation snapshot encryption in kernel space,
> 2. the key derivation implementation in user space.
> 
> Please refer to each patch for detail, and feel free to comment on
> this, thanks.
> 
> [1] https://www.spinics.net/lists/linux-crypto/msg33145.html
> 
> Chen Yu (3):
>   PM / Hibernate: Add helper functions for hibernation encryption
>   PM / Hibernate: Encrypt the snapshot pages before submitted to the
> block device
>   tools: create power/crypto utility
>

I am trying this patch set.

Could you please tell me how to test the user space crypto utility with
systemd's hibernation module? 

I have a question about the salt. If the salt is saved in image header,
does that mean that kernel needs to read the image header before user
space crypto utility be launched? Otherwise user space can not get
the salt to produce key? I a bit confused about the resume process.

Thanks
Joey Lee 

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[joeyli]

Hi Chen Yu, 

On Wed, Jun 20, 2018 at 05:39:37PM +0800, Chen Yu wrote:
> Hi,
> As security becomes more and more important, we add the in-kernel
> encryption support for hibernation.
> 
> This prototype is a trial version to implement the hibernation
> encryption in the kernel, so that the users do not have to rely
> on third-party tools to encrypt the hibernation image. The only
> dependency on user space is that, the user space should provide
> a valid key derived from passphrase to the kernel for image encryption.
> 
> There was a discussion on the mailing list on whether this key should
> be derived in kernel or in user space. And it turns out to be generating
> the key by user space is more acceptable[1]. So this patch set is divided
> into two parts:
> 1. The hibernation snapshot encryption in kernel space,
> 2. the key derivation implementation in user space.
> 
> Please refer to each patch for detail, and feel free to comment on
> this, thanks.
> 
> [1] https://www.spinics.net/lists/linux-crypto/msg33145.html
> 
> Chen Yu (3):
>   PM / Hibernate: Add helper functions for hibernation encryption
>   PM / Hibernate: Encrypt the snapshot pages before submitted to the
> block device
>   tools: create power/crypto utility
>

I am trying this patch set.

Could you please tell me how to test the user space crypto utility with
systemd's hibernation module? 

I have a question about the salt. If the salt is saved in image header,
does that mean that kernel needs to read the image header before user
space crypto utility be launched? Otherwise user space can not get
the salt to produce key? I a bit confused about the resume process.

Thanks
Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > Hi,
> > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > Hi Chen Yu,
> > > > 
> > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > Use the helper functions introduced previously to encrypt
> > > > > the page data before they are submitted to the block device.
> > > > > Besides, for the case of hibernation compression, the data
> > > > > are firstly compressed and then encrypted, and vice versa
> > > > > for the resume process.
> > > > >
> > > > 
> > > > I want to suggest my solution that it direct signs/encrypts the
> > > > memory snapshot image. This solution is already shipped with
> > > > SLE12 a couple of years:
> > > > 
> > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > 
> > > I did not see image page encryption in above link, if I understand
> > 
> > PM / hibernate: Generate and verify signature for snapshot image
> > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> >
> > PM / hibernate: snapshot image encryption
> > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> >
> > The above patches sign and encrypt the data pages in snapshot image.
> > It puts the signature to header.
> >
> It looks like your signature code can be simplyly added on top of the
> solution we proposed here, how about we collaborating on this task?

OK, I will base on your user key solution to respin my signature patches.
 
> just my 2 cents, 
> 1. The cryption code should be indepent of the snapshot code, and
>this is why we implement it as a kernel module for that in PATCH[1/3].

Why the cryption code must be indepent of snapshot code?

> 2. There's no need to traverse the snapshot image twice, if the
>image is large(there's requirement on servers now) we can
>simplyly do the encryption before the disk IO, and this is
>why PATCH[2/3] looks like this.

If the encryption solution is only for block device, then the uswsusp
interface must be locked-down when kernel is in locked mode:

uswsusp: Disable when the kernel is locked down
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612

I still suggest to keep the solution to direct encript the snapshot
image for uswsusp because the snapshot can be encrypted by kernel
before user space get it.

I mean that if the uswsusp be used, then kernel direct encrypts the
snapshot image, otherwise kernel encrypts pages before block io.

On the other hand, I have a question about asynchronous block io.
Please see below...

> > > > > Suggested-by: Rafael J. Wysocki 
> > > > > Cc: Rafael J. Wysocki 
> > > > > Cc: Pavel Machek 
> > > > > Cc: Len Brown 
> > > > > Cc: Borislav Petkov 
> > > > > Cc: "Lee, Chun-Yi" 
> > > > > Cc: linux...@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Signed-off-by: Chen Yu 
> > > > > ---
> > > > >  kernel/power/power.h |   1 +
> > > > >  kernel/power/swap.c  | 215 
> > > > > ---
> > > > >  2 files changed, 205 insertions(+), 11 deletions(-)
[...snip]
> > > > >  /* kernel/power/hibernate.c */
> > > > >  extern int swsusp_check(void);
> > > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > > index c2bcf97..2b6b3d0 100644
> > > > > --- a/kernel/power/swap.c
> > > > > +++ b/kernel/power/swap.c
[...snip]
> > > > > @@ -1069,18 +1171,42 @@ static int load_image(struct swap_map_handle 
> > > > > *handle,
> > > > >   if (!m)
> > > > >   m = 1;
> > > > >   nr_pages = 0;
> > > > > + crypto_page_idx = 0;
> > > > > + if (handle->crypto) {
> > > > > + crypt_buf = (void *)get_zeroed_page(GFP_KERNEL);
> > > > > + if (!crypt_buf)
> > > > > + return -ENOMEM;
> > > > > + }
> > > > >   start = ktime_get();
> > > > >   for ( ; ; ) {
>

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > Hi,
> > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > Hi Chen Yu,
> > > > 
> > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > Use the helper functions introduced previously to encrypt
> > > > > the page data before they are submitted to the block device.
> > > > > Besides, for the case of hibernation compression, the data
> > > > > are firstly compressed and then encrypted, and vice versa
> > > > > for the resume process.
> > > > >
> > > > 
> > > > I want to suggest my solution that it direct signs/encrypts the
> > > > memory snapshot image. This solution is already shipped with
> > > > SLE12 a couple of years:
> > > > 
> > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > 
> > > I did not see image page encryption in above link, if I understand
> > 
> > PM / hibernate: Generate and verify signature for snapshot image
> > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> >
> > PM / hibernate: snapshot image encryption
> > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> >
> > The above patches sign and encrypt the data pages in snapshot image.
> > It puts the signature to header.
> >
> It looks like your signature code can be simplyly added on top of the
> solution we proposed here, how about we collaborating on this task?

OK, I will base on your user key solution to respin my signature patches.
 
> just my 2 cents, 
> 1. The cryption code should be indepent of the snapshot code, and
>this is why we implement it as a kernel module for that in PATCH[1/3].

Why the cryption code must be indepent of snapshot code?

> 2. There's no need to traverse the snapshot image twice, if the
>image is large(there's requirement on servers now) we can
>simplyly do the encryption before the disk IO, and this is
>why PATCH[2/3] looks like this.

If the encryption solution is only for block device, then the uswsusp
interface must be locked-down when kernel is in locked mode:

uswsusp: Disable when the kernel is locked down
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612

I still suggest to keep the solution to direct encript the snapshot
image for uswsusp because the snapshot can be encrypted by kernel
before user space get it.

I mean that if the uswsusp be used, then kernel direct encrypts the
snapshot image, otherwise kernel encrypts pages before block io.

On the other hand, I have a question about asynchronous block io.
Please see below...

> > > > > Suggested-by: Rafael J. Wysocki 
> > > > > Cc: Rafael J. Wysocki 
> > > > > Cc: Pavel Machek 
> > > > > Cc: Len Brown 
> > > > > Cc: Borislav Petkov 
> > > > > Cc: "Lee, Chun-Yi" 
> > > > > Cc: linux...@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Signed-off-by: Chen Yu 
> > > > > ---
> > > > >  kernel/power/power.h |   1 +
> > > > >  kernel/power/swap.c  | 215 
> > > > > ---
> > > > >  2 files changed, 205 insertions(+), 11 deletions(-)
[...snip]
> > > > >  /* kernel/power/hibernate.c */
> > > > >  extern int swsusp_check(void);
> > > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > > index c2bcf97..2b6b3d0 100644
> > > > > --- a/kernel/power/swap.c
> > > > > +++ b/kernel/power/swap.c
[...snip]
> > > > > @@ -1069,18 +1171,42 @@ static int load_image(struct swap_map_handle 
> > > > > *handle,
> > > > >   if (!m)
> > > > >   m = 1;
> > > > >   nr_pages = 0;
> > > > > + crypto_page_idx = 0;
> > > > > + if (handle->crypto) {
> > > > > + crypt_buf = (void *)get_zeroed_page(GFP_KERNEL);
> > > > > + if (!crypt_buf)
> > > > > + return -ENOMEM;
> > > > > + }
> > > > >   start = ktime_get();
> > > > >   for ( ; ; ) {
>

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > Hi Chen Yu,
> > 
> > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > Use the helper functions introduced previously to encrypt
> > > the page data before they are submitted to the block device.
> > > Besides, for the case of hibernation compression, the data
> > > are firstly compressed and then encrypted, and vice versa
> > > for the resume process.
> > >
> > 
> > I want to suggest my solution that it direct signs/encrypts the
> > memory snapshot image. This solution is already shipped with
> > SLE12 a couple of years:
> > 
> > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > 
> I did not see image page encryption in above link, if I understand

PM / hibernate: Generate and verify signature for snapshot image
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f

PM / hibernate: snapshot image encryption
https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929

The above patches sign and encrypt the data pages in snapshot image.
It puts the signature to header.

> correctly, your code focus on signation and encrypt the hidden data,
> but not target for the whole snapshot data.

Please ignore the hidden area because we already encrypted snapshot image.
Those data doesn't need to erase from snapshot anymore. I will remove
the hidden area patches in next version. 

> > The above patches still need to clean up. I am working on some
> > other bugs, but I can clean up and send out it ASAP.
> > 
> > The advantage of this solution is that it produces a signed and
> > encrypted image. Not just for writing to block device by kernel,
> > it also can provide a signed/encrypted image to user space. User
> > space can store the encrypted image to anywhere.
> > 
> > I am OK for your user space key generator because I didn't have
> > similar solution yet. I am working on the EFI master key and also
> > want to adapt hibernation to keyring. I will continue the works.
> > 
> The user space tool can easily add the keyring support besides
> ioctl if needed.
>

Understood.

Thanks
Joey Lee
 
> Best,
> Yu
> > Thanks a lot!
> > Joey Lee
> >  
> > > Suggested-by: Rafael J. Wysocki 
> > > Cc: Rafael J. Wysocki 
> > > Cc: Pavel Machek 
> > > Cc: Len Brown 
> > > Cc: Borislav Petkov 
> > > Cc: "Lee, Chun-Yi" 
> > > Cc: linux...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Chen Yu 
> > > ---
> > >  kernel/power/power.h |   1 +
> > >  kernel/power/swap.c  | 215 
> > > ---
> > >  2 files changed, 205 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > > index 660aac3..637695c 100644
> > > --- a/kernel/power/power.h
> > > +++ b/kernel/power/power.h
> > > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> > >  #define SF_PLATFORM_MODE 1
> > >  #define SF_NOCOMPRESS_MODE   2
> > >  #define SF_CRC32_MODE4
> > > +#define SF_ENCRYPT_MODE  8
> > >  
> > >  /* kernel/power/hibernate.c */
> > >  extern int swsusp_check(void);
> > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > index c2bcf97..2b6b3d0 100644
> > > --- a/kernel/power/swap.c
> > > +++ b/kernel/power/swap.c
> > > @@ -102,14 +102,16 @@ struct swap_map_handle {
> > >   unsigned int k;
> > >   unsigned long reqd_free_pages;
> > >   u32 crc32;
> > > + bool crypto;
> > >  };
> > >  
> > >  struct swsusp_header {
> > >   char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> > > -   sizeof(u32)];
> > > + sizeof(u32) - HIBERNATE_SALT_BYTES];
> > >   u32 crc32;
> > >   sector_t image;
> > >   unsigned int flags; /* Flags to pass to the "boot" kernel */
> > > + char salt[HIBERNATE_SALT_BYTES];
> > >   charorig_sig[10];
> > >   charsig[10];
> > >  } __packed;
> > > @@ -127,6 +129,53 @@ struct swsusp_extent {
> > >   unsigned long end;
> > >  };
> > >  
> > > +/* For encryption/decryption. */
> > > +static struct hibernation_crypto *hibernation_crypto_ops;
> > > +
> 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> Hi,
> On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > Hi Chen Yu,
> > 
> > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > Use the helper functions introduced previously to encrypt
> > > the page data before they are submitted to the block device.
> > > Besides, for the case of hibernation compression, the data
> > > are firstly compressed and then encrypted, and vice versa
> > > for the resume process.
> > >
> > 
> > I want to suggest my solution that it direct signs/encrypts the
> > memory snapshot image. This solution is already shipped with
> > SLE12 a couple of years:
> > 
> > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > 
> I did not see image page encryption in above link, if I understand

PM / hibernate: Generate and verify signature for snapshot image
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f

PM / hibernate: snapshot image encryption
https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929

The above patches sign and encrypt the data pages in snapshot image.
It puts the signature to header.

> correctly, your code focus on signation and encrypt the hidden data,
> but not target for the whole snapshot data.

Please ignore the hidden area because we already encrypted snapshot image.
Those data doesn't need to erase from snapshot anymore. I will remove
the hidden area patches in next version. 

> > The above patches still need to clean up. I am working on some
> > other bugs, but I can clean up and send out it ASAP.
> > 
> > The advantage of this solution is that it produces a signed and
> > encrypted image. Not just for writing to block device by kernel,
> > it also can provide a signed/encrypted image to user space. User
> > space can store the encrypted image to anywhere.
> > 
> > I am OK for your user space key generator because I didn't have
> > similar solution yet. I am working on the EFI master key and also
> > want to adapt hibernation to keyring. I will continue the works.
> > 
> The user space tool can easily add the keyring support besides
> ioctl if needed.
>

Understood.

Thanks
Joey Lee
 
> Best,
> Yu
> > Thanks a lot!
> > Joey Lee
> >  
> > > Suggested-by: Rafael J. Wysocki 
> > > Cc: Rafael J. Wysocki 
> > > Cc: Pavel Machek 
> > > Cc: Len Brown 
> > > Cc: Borislav Petkov 
> > > Cc: "Lee, Chun-Yi" 
> > > Cc: linux...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Chen Yu 
> > > ---
> > >  kernel/power/power.h |   1 +
> > >  kernel/power/swap.c  | 215 
> > > ---
> > >  2 files changed, 205 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > > index 660aac3..637695c 100644
> > > --- a/kernel/power/power.h
> > > +++ b/kernel/power/power.h
> > > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> > >  #define SF_PLATFORM_MODE 1
> > >  #define SF_NOCOMPRESS_MODE   2
> > >  #define SF_CRC32_MODE4
> > > +#define SF_ENCRYPT_MODE  8
> > >  
> > >  /* kernel/power/hibernate.c */
> > >  extern int swsusp_check(void);
> > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > index c2bcf97..2b6b3d0 100644
> > > --- a/kernel/power/swap.c
> > > +++ b/kernel/power/swap.c
> > > @@ -102,14 +102,16 @@ struct swap_map_handle {
> > >   unsigned int k;
> > >   unsigned long reqd_free_pages;
> > >   u32 crc32;
> > > + bool crypto;
> > >  };
> > >  
> > >  struct swsusp_header {
> > >   char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> > > -   sizeof(u32)];
> > > + sizeof(u32) - HIBERNATE_SALT_BYTES];
> > >   u32 crc32;
> > >   sector_t image;
> > >   unsigned int flags; /* Flags to pass to the "boot" kernel */
> > > + char salt[HIBERNATE_SALT_BYTES];
> > >   charorig_sig[10];
> > >   charsig[10];
> > >  } __packed;
> > > @@ -127,6 +129,53 @@ struct swsusp_extent {
> > >   unsigned long end;
> > >  };
> > >  
> > > +/* For encryption/decryption. */
> > > +static struct hibernation_crypto *hibernation_crypto_ops;
> > > +
> 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

Hi Chen Yu,

On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> Use the helper functions introduced previously to encrypt
> the page data before they are submitted to the block device.
> Besides, for the case of hibernation compression, the data
> are firstly compressed and then encrypted, and vice versa
> for the resume process.
>

I want to suggest my solution that it direct signs/encrypts the
memory snapshot image. This solution is already shipped with
SLE12 a couple of years:

https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3

The above patches still need to clean up. I am working on some
other bugs, but I can clean up and send out it ASAP.

The advantage of this solution is that it produces a signed and
encrypted image. Not just for writing to block device by kernel,
it also can provide a signed/encrypted image to user space. User
space can store the encrypted image to anywhere.

I am OK for your user space key generator because I didn't have
similar solution yet. I am working on the EFI master key and also
want to adapt hibernation to keyring. I will continue the works.

Thanks a lot!
Joey Lee
 
> Suggested-by: Rafael J. Wysocki 
> Cc: Rafael J. Wysocki 
> Cc: Pavel Machek 
> Cc: Len Brown 
> Cc: Borislav Petkov 
> Cc: "Lee, Chun-Yi" 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Chen Yu 
> ---
>  kernel/power/power.h |   1 +
>  kernel/power/swap.c  | 215 
> ---
>  2 files changed, 205 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 660aac3..637695c 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
>  #define SF_PLATFORM_MODE 1
>  #define SF_NOCOMPRESS_MODE   2
>  #define SF_CRC32_MODE4
> +#define SF_ENCRYPT_MODE  8
>  
>  /* kernel/power/hibernate.c */
>  extern int swsusp_check(void);
> diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> index c2bcf97..2b6b3d0 100644
> --- a/kernel/power/swap.c
> +++ b/kernel/power/swap.c
> @@ -102,14 +102,16 @@ struct swap_map_handle {
>   unsigned int k;
>   unsigned long reqd_free_pages;
>   u32 crc32;
> + bool crypto;
>  };
>  
>  struct swsusp_header {
>   char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> -   sizeof(u32)];
> + sizeof(u32) - HIBERNATE_SALT_BYTES];
>   u32 crc32;
>   sector_t image;
>   unsigned int flags; /* Flags to pass to the "boot" kernel */
> + char salt[HIBERNATE_SALT_BYTES];
>   charorig_sig[10];
>   charsig[10];
>  } __packed;
> @@ -127,6 +129,53 @@ struct swsusp_extent {
>   unsigned long end;
>  };
>  
> +/* For encryption/decryption. */
> +static struct hibernation_crypto *hibernation_crypto_ops;
> +
> +void set_hibernation_ops(struct hibernation_crypto *ops)
> +{
> + hibernation_crypto_ops = ops;
> +}
> +EXPORT_SYMBOL_GPL(set_hibernation_ops);
> +
> +static int crypto_data(const char *inbuf,
> + int inlen,
> + char *outbuf,
> + int outlen,
> + bool encrypt,
> + int page_idx)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->crypto_data)
> + return hibernation_crypto_ops->crypto_data(inbuf,
> + inlen, outbuf, outlen, encrypt, page_idx);
> + else
> + return -EINVAL;
> +}
> +
> +static void crypto_save(void *outbuf)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->save)
> + hibernation_crypto_ops->save(outbuf);
> +}
> +
> +static void crypto_restore(void *inbuf)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->restore)
> + hibernation_crypto_ops->restore(inbuf);
> +}
> +
> +static int crypto_init(bool suspend)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->init)
> + return hibernation_crypto_ops->init(suspend);
> + else
> + return -EINVAL;
> +}
> +
>  static struct rb_root swsusp_extents = RB_ROOT;
>  
>  static int swsusp_extents_insert(unsigned long swap_offset)
> @@ -318,6 +367,10 @@ static int mark_swapfiles(struct swap_map_handle 
> *handle, unsigned int flags)
>   swsusp_header->flags = flags;
>   if (flags & SF_CRC32_MODE)
> 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[joeyli]

Hi Chen Yu,

On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> Use the helper functions introduced previously to encrypt
> the page data before they are submitted to the block device.
> Besides, for the case of hibernation compression, the data
> are firstly compressed and then encrypted, and vice versa
> for the resume process.
>

I want to suggest my solution that it direct signs/encrypts the
memory snapshot image. This solution is already shipped with
SLE12 a couple of years:

https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3

The above patches still need to clean up. I am working on some
other bugs, but I can clean up and send out it ASAP.

The advantage of this solution is that it produces a signed and
encrypted image. Not just for writing to block device by kernel,
it also can provide a signed/encrypted image to user space. User
space can store the encrypted image to anywhere.

I am OK for your user space key generator because I didn't have
similar solution yet. I am working on the EFI master key and also
want to adapt hibernation to keyring. I will continue the works.

Thanks a lot!
Joey Lee
 
> Suggested-by: Rafael J. Wysocki 
> Cc: Rafael J. Wysocki 
> Cc: Pavel Machek 
> Cc: Len Brown 
> Cc: Borislav Petkov 
> Cc: "Lee, Chun-Yi" 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Chen Yu 
> ---
>  kernel/power/power.h |   1 +
>  kernel/power/swap.c  | 215 
> ---
>  2 files changed, 205 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 660aac3..637695c 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
>  #define SF_PLATFORM_MODE 1
>  #define SF_NOCOMPRESS_MODE   2
>  #define SF_CRC32_MODE4
> +#define SF_ENCRYPT_MODE  8
>  
>  /* kernel/power/hibernate.c */
>  extern int swsusp_check(void);
> diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> index c2bcf97..2b6b3d0 100644
> --- a/kernel/power/swap.c
> +++ b/kernel/power/swap.c
> @@ -102,14 +102,16 @@ struct swap_map_handle {
>   unsigned int k;
>   unsigned long reqd_free_pages;
>   u32 crc32;
> + bool crypto;
>  };
>  
>  struct swsusp_header {
>   char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> -   sizeof(u32)];
> + sizeof(u32) - HIBERNATE_SALT_BYTES];
>   u32 crc32;
>   sector_t image;
>   unsigned int flags; /* Flags to pass to the "boot" kernel */
> + char salt[HIBERNATE_SALT_BYTES];
>   charorig_sig[10];
>   charsig[10];
>  } __packed;
> @@ -127,6 +129,53 @@ struct swsusp_extent {
>   unsigned long end;
>  };
>  
> +/* For encryption/decryption. */
> +static struct hibernation_crypto *hibernation_crypto_ops;
> +
> +void set_hibernation_ops(struct hibernation_crypto *ops)
> +{
> + hibernation_crypto_ops = ops;
> +}
> +EXPORT_SYMBOL_GPL(set_hibernation_ops);
> +
> +static int crypto_data(const char *inbuf,
> + int inlen,
> + char *outbuf,
> + int outlen,
> + bool encrypt,
> + int page_idx)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->crypto_data)
> + return hibernation_crypto_ops->crypto_data(inbuf,
> + inlen, outbuf, outlen, encrypt, page_idx);
> + else
> + return -EINVAL;
> +}
> +
> +static void crypto_save(void *outbuf)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->save)
> + hibernation_crypto_ops->save(outbuf);
> +}
> +
> +static void crypto_restore(void *inbuf)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->restore)
> + hibernation_crypto_ops->restore(inbuf);
> +}
> +
> +static int crypto_init(bool suspend)
> +{
> + if (hibernation_crypto_ops &&
> + hibernation_crypto_ops->init)
> + return hibernation_crypto_ops->init(suspend);
> + else
> + return -EINVAL;
> +}
> +
>  static struct rb_root swsusp_extents = RB_ROOT;
>  
>  static int swsusp_extents_insert(unsigned long swap_offset)
> @@ -318,6 +367,10 @@ static int mark_swapfiles(struct swap_map_handle 
> *handle, unsigned int flags)
>   swsusp_header->flags = flags;
>   if (flags & SF_CRC32_MODE)
> 

Re: [systemd-devel] [PATCH] detect-virt: do not return exit failure code when the state is none

[joeyli]

Hi Lennart, 

Thanks for your review and response...

On Thu, May 24, 2018 at 12:20:36PM +0200, Lennart Poettering wrote:
> On Do, 24.05.18 13:47, Lee, Chun-Yi (joeyli.ker...@gmail.com) wrote:
> 
> > Currently the systemd-detect-virt returns exit failure code when it
> > detected none state. But actually the none state is still a valid
> > state but not a process failed.
> > 
> > This patch changes the logic to return success code when the state
> > is none. It can avoid that subsequent activity is blocked by the
> > failure code of systemd-detect-virt process.
> 
> This is supposed to be used in shell script constructs like the
> following:
> 
> 
> if systemd-detect-virt -q ; then
> echo "Detected virtualization"
> else
> echo "Detected no virtualization"
> fi
> 
> 
> That exit code hence is used as boolean indication whether
> virtualization is available or not. And this behaviour is explicitly
> documented in the man page. It's API and for a good reason so. Even if
> we could break API just like that we really shouldn't because such if
> constructs make a ton of sense and are generally how shell does this,
> see the "test" command for example.
> 
> Sorry, but you need to find a different way to do what you are trying
> to do...
> 
> Sorry,
>

hm I avoid writing script by "RUN+=" in the rule.

Do you have good idea to inhibit the exit failure to avoid the subsequent
activity be blocked?

Or, can we add a new option to systemd-detect-virt to inhibit the exit
failure code when the state is none?  

Thanks a lot!
Joey Lee
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

[joeyli]

Hi experts, 

Sorry for I missed this discussion...

On Thu, Apr 26, 2018 at 10:20:29AM +0200, Jiri Kosina wrote:
> On Thu, 26 Apr 2018, Pavel Machek wrote:
> 
> > That's not how the crypto needs to work. Talk to Jiri Kosina, ok?
> 
> Yeah, Joey Lee (adding to CC) implemented it here:
> 
>   https://lkml.org/lkml/2015/8/11/47
> 
> I think there have been more respins, Joey definitely knows more details 
> and status quo.
> 
> The design is specifically tailored for secure-boot environments though.
>

I am working on the next version of hibernation encryption and authentication:
https://github.com/joeyli/linux-s4sign/wiki 

My plan is:

- Hibernation encryption:
  There is a draft patch to encrypt image by ctr(aes). This patch works
  with the first version of hibernation verification:
  
https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929

- Adapt hibernation to key retention service:
- Using the encrypted key to derive encrypt key and auth key to
  encrypt and hmac snapshot image. Put the encrypted key in the image
  header of snapshot.
- The encrypted key will be encrypted by KMK (kernel master key). Either
  trusted key(sealed by TPM) or EFI key (explain in later) can be the KMK.
  If there have appropriate UI support in initrd, user key can also be
  the KMK.
- Similar with the enrolling EVM key, but more earler:
  The systemd and dracut must be changed for enrolling kernel master key
  before the swap partition be mounted.

- EFI key:
- A new master key type to key retention service.
- It can be a new option beyond trusted key(TPM) and user key.
- EFI stub generates a random key and stores in EFI boot service
  variable:
- This random key in boot variable can be called ERK (EFI Root Key)
- The ERK is secure when secure boot enabled.
- User must aware and enable secure boot by themself if they want.
- ERK can be a secret to encrypt a random number for generate a EFI key
   - The EFI key can be used by hibernation encryption/authentication.
   - The EFI key can be a master key to generate a encrypted key for 
EVM.
- Rescue mechanism for ERK:
- The ERK may be regenerated after the old ERK be erased by firmware 
update
  or firmware recovery.
- Current idea is using the public key in first/second trusted keyring
  to encrypt the ERK for backup. User can enroll the EFI key with old 
ERK to
  request kernel to re-encrypt the EFI key with new ERK.


Thanks a lot!
Joey Lee

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

[joeyli]

Hi experts, 

Sorry for I missed this discussion...

On Thu, Apr 26, 2018 at 10:20:29AM +0200, Jiri Kosina wrote:
> On Thu, 26 Apr 2018, Pavel Machek wrote:
> 
> > That's not how the crypto needs to work. Talk to Jiri Kosina, ok?
> 
> Yeah, Joey Lee (adding to CC) implemented it here:
> 
>   https://lkml.org/lkml/2015/8/11/47
> 
> I think there have been more respins, Joey definitely knows more details 
> and status quo.
> 
> The design is specifically tailored for secure-boot environments though.
>

I am working on the next version of hibernation encryption and authentication:
https://github.com/joeyli/linux-s4sign/wiki 

My plan is:

- Hibernation encryption:
  There is a draft patch to encrypt image by ctr(aes). This patch works
  with the first version of hibernation verification:
  
https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929

- Adapt hibernation to key retention service:
- Using the encrypted key to derive encrypt key and auth key to
  encrypt and hmac snapshot image. Put the encrypted key in the image
  header of snapshot.
- The encrypted key will be encrypted by KMK (kernel master key). Either
  trusted key(sealed by TPM) or EFI key (explain in later) can be the KMK.
  If there have appropriate UI support in initrd, user key can also be
  the KMK.
- Similar with the enrolling EVM key, but more earler:
  The systemd and dracut must be changed for enrolling kernel master key
  before the swap partition be mounted.

- EFI key:
- A new master key type to key retention service.
- It can be a new option beyond trusted key(TPM) and user key.
- EFI stub generates a random key and stores in EFI boot service
  variable:
- This random key in boot variable can be called ERK (EFI Root Key)
- The ERK is secure when secure boot enabled.
- User must aware and enable secure boot by themself if they want.
- ERK can be a secret to encrypt a random number for generate a EFI key
   - The EFI key can be used by hibernation encryption/authentication.
   - The EFI key can be a master key to generate a encrypted key for 
EVM.
- Rescue mechanism for ERK:
- The ERK may be regenerated after the old ERK be erased by firmware 
update
  or firmware recovery.
- Current idea is using the public key in first/second trusted keyring
  to encrypt the ERK for backup. User can enroll the EFI key with old 
ERK to
  request kernel to re-encrypt the EFI key with new ERK.


Thanks a lot!
Joey Lee

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

[joeyli]

Hi Ard,

On Thu, May 03, 2018 at 02:05:51PM +0200, Ard Biesheuvel wrote:
> On 2 May 2018 at 08:17, Lee, Chun-Yi  wrote:
> > When using kdump, SOMETIMES the "size not consistent" warning message
> > shows up when the crash kernel boots with early_ioremap_debug parameter:
> >
> > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 
> > early_iounmap+0x4f/0x12c()
> > early_iounmap(ff200180, 0118) [0] size not consistent 0120
> >
> > The root cause is that the unmapping size of memory map doesn't
> > match with the original size when mapping:
> >
> > in __efi_memmap_init()
> > map.map = early_memremap(phys_map, data->size);
> >
> > in efi_memmap_unmap()
> > size = efi.memmap.desc_size * efi.memmap.nr_map;
> > early_memunmap(efi.memmap.map, size);
> >
> > But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder
> > of size was discarded when calculating the nr_map:
> > map.nr_map = data->size / data->desc_size;
> >
> > When the original size of memory map region does not equal to the
> > result of multiplication. The "size not consistent" warning
> > will be triggered.
> >
> > This issue sometimes was hit by kdump because kexec set the efi map
> > size to align with 16 when loading crash kernel image:
> >
> > in bzImage64_load()
> > efi_map_sz = efi_get_runtime_map_size();
> > efi_map_sz = ALIGN(efi_map_sz, 16);
> >
> > Dave Young's a841aa83d patch fixed kexec issue. On UEFI side, this
> > patch changes the logic in the unmapping function. Using the end
> > address of map to calcuate original size.
> >
> 
> Why do we still need this patch? I.e., in which circumstances will
> efi_memory_map_data::size assume a value that is rounded up or
> otherwise incorrect?
>

There have no other case except kexec. But I think that it's better
to sync mapping/unmapping size between __efi_memmap_init() and 
efi_memmap_unmap(). 


Thanks
Joey Lee
 
> > Thank Randy Wright for his report and testing. And also thank
> > Takashi Iwai for his help to trace issue.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Takashi Iwai 
> > Cc: Vivek Goyal 
> > Cc: Ingo Molnar 
> > Tested-by: Randy Wright 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/firmware/efi/memmap.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> > index 5fc7052..1f592d8 100644
> > --- a/drivers/firmware/efi/memmap.c
> > +++ b/drivers/firmware/efi/memmap.c
> > @@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void)
> > if (!efi.memmap.late) {
> > unsigned long size;
> >
> > -   size = efi.memmap.desc_size * efi.memmap.nr_map;
> > +   size = efi.memmap.map_end - efi.memmap.map;
> > early_memunmap(efi.memmap.map, size);
> > } else {
> > memunmap(efi.memmap.map);
> > --
> > 2.10.2
> >

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

[joeyli]

Hi Ard,

On Thu, May 03, 2018 at 02:05:51PM +0200, Ard Biesheuvel wrote:
> On 2 May 2018 at 08:17, Lee, Chun-Yi  wrote:
> > When using kdump, SOMETIMES the "size not consistent" warning message
> > shows up when the crash kernel boots with early_ioremap_debug parameter:
> >
> > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 
> > early_iounmap+0x4f/0x12c()
> > early_iounmap(ff200180, 0118) [0] size not consistent 0120
> >
> > The root cause is that the unmapping size of memory map doesn't
> > match with the original size when mapping:
> >
> > in __efi_memmap_init()
> > map.map = early_memremap(phys_map, data->size);
> >
> > in efi_memmap_unmap()
> > size = efi.memmap.desc_size * efi.memmap.nr_map;
> > early_memunmap(efi.memmap.map, size);
> >
> > But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder
> > of size was discarded when calculating the nr_map:
> > map.nr_map = data->size / data->desc_size;
> >
> > When the original size of memory map region does not equal to the
> > result of multiplication. The "size not consistent" warning
> > will be triggered.
> >
> > This issue sometimes was hit by kdump because kexec set the efi map
> > size to align with 16 when loading crash kernel image:
> >
> > in bzImage64_load()
> > efi_map_sz = efi_get_runtime_map_size();
> > efi_map_sz = ALIGN(efi_map_sz, 16);
> >
> > Dave Young's a841aa83d patch fixed kexec issue. On UEFI side, this
> > patch changes the logic in the unmapping function. Using the end
> > address of map to calcuate original size.
> >
> 
> Why do we still need this patch? I.e., in which circumstances will
> efi_memory_map_data::size assume a value that is rounded up or
> otherwise incorrect?
>

There have no other case except kexec. But I think that it's better
to sync mapping/unmapping size between __efi_memmap_init() and 
efi_memmap_unmap(). 


Thanks
Joey Lee
 
> > Thank Randy Wright for his report and testing. And also thank
> > Takashi Iwai for his help to trace issue.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Takashi Iwai 
> > Cc: Vivek Goyal 
> > Cc: Ingo Molnar 
> > Tested-by: Randy Wright 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/firmware/efi/memmap.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> > index 5fc7052..1f592d8 100644
> > --- a/drivers/firmware/efi/memmap.c
> > +++ b/drivers/firmware/efi/memmap.c
> > @@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void)
> > if (!efi.memmap.late) {
> > unsigned long size;
> >
> > -   size = efi.memmap.desc_size * efi.memmap.nr_map;
> > +   size = efi.memmap.map_end - efi.memmap.map;
> > early_memunmap(efi.memmap.map, size);
> > } else {
> > memunmap(efi.memmap.map);
> > --
> > 2.10.2
> >

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

[joeyli]

Hi Ard,

On Thu, May 03, 2018 at 02:05:51PM +0200, Ard Biesheuvel wrote:
> On 2 May 2018 at 08:17, Lee, Chun-Yi  wrote:
> > When using kdump, SOMETIMES the "size not consistent" warning message
> > shows up when the crash kernel boots with early_ioremap_debug parameter:
> >
> > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 
> > early_iounmap+0x4f/0x12c()
> > early_iounmap(ff200180, 0118) [0] size not consistent 0120
> >
> > The root cause is that the unmapping size of memory map doesn't
> > match with the original size when mapping:
> >
> > in __efi_memmap_init()
> > map.map = early_memremap(phys_map, data->size);
> >
> > in efi_memmap_unmap()
> > size = efi.memmap.desc_size * efi.memmap.nr_map;
> > early_memunmap(efi.memmap.map, size);
> >
> > But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder
> > of size was discarded when calculating the nr_map:
> > map.nr_map = data->size / data->desc_size;
> >
> > When the original size of memory map region does not equal to the
> > result of multiplication. The "size not consistent" warning
> > will be triggered.
> >
> > This issue sometimes was hit by kdump because kexec set the efi map
> > size to align with 16 when loading crash kernel image:
> >
> > in bzImage64_load()
> > efi_map_sz = efi_get_runtime_map_size();
> > efi_map_sz = ALIGN(efi_map_sz, 16);
> >
> > Dave Young's a841aa83d patch fixed kexec issue. On UEFI side, this
> > patch changes the logic in the unmapping function. Using the end
> > address of map to calcuate original size.
> >
> 
> Why do we still need this patch? I.e., in which circumstances will
> efi_memory_map_data::size assume a value that is rounded up or
> otherwise incorrect?
>

There have no other case except kexec. But I think that it's better
to sync mapping/unmapping size between __efi_memmap_init() and 
efi_memmap_unmap(). 


Thanks
Joey Lee
 
> > Thank Randy Wright for his report and testing. And also thank
> > Takashi Iwai for his help to trace issue.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Takashi Iwai 
> > Cc: Vivek Goyal 
> > Cc: Ingo Molnar 
> > Tested-by: Randy Wright 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/firmware/efi/memmap.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> > index 5fc7052..1f592d8 100644
> > --- a/drivers/firmware/efi/memmap.c
> > +++ b/drivers/firmware/efi/memmap.c
> > @@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void)
> > if (!efi.memmap.late) {
> > unsigned long size;
> >
> > -   size = efi.memmap.desc_size * efi.memmap.nr_map;
> > +   size = efi.memmap.map_end - efi.memmap.map;
> > early_memunmap(efi.memmap.map, size);
> > } else {
> > memunmap(efi.memmap.map);
> > --
> > 2.10.2
> >
--
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] efi: Fix the size not consistent issue when unmapping memory map

[joeyli]

On Mon, Apr 16, 2018 at 06:35:22PM -0600, Randy Wright wrote:
> On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote:
> > Hi Randy,
> > ...
> > Randy, do you want to try Dave's kexec patch on your environment? Please 
> > remove
> > my patch first.  
> > 
> > Thanks a lot!
> > Joey Lee
> 
> Hi Joey, 
> 
> I tried Dave's patch to kexec-bzimage64.c on my build of the SuSE
> 4.12.14-15 kernel.   I ran the same test as I did with your patch: I
> verified the early_ioremap.c warnings occurred with a crash triggered
> from a kexec boot of the unmodified kernel. Then I applied the patch to
> kexec-bzimage64.c, rebuilt, re-ran the test to crash from the kexec'ed
> kernel, and verified the warnings are no longer seen.
>

Thanks for your help! Looks that Dave's kexec patch works to prevent the
warning message. 
 
> I'm out of time today, but I will plan to run the same  test tomorrow on
> a build of the SuSE 4.4.120-94.17 kernel, on which I had also reported
> the original bug.
>

Both kexec and efi sides will be applied patches.

Thanks a lot!
Joey Lee 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec