於 日，2013-09-01 於 18:40 +0200，Florian Weimer 提到：
> * Matthew Garrett:
>
> > On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> >
> >> But if you don't generate fresh keys on every boot, the persistent
> >> keys are mor exposed to other UEFI applications. Correct me if I'm
> >>
On Sun, Sep 01, 2013 at 06:40:41PM +0200, Florian Weimer wrote:
> * Matthew Garrett:
>
> > On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> >
> >> But if you don't generate fresh keys on every boot, the persistent
> >> keys are mor exposed to other UEFI applications. Correct me
* Matthew Garrett:
> On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
>
>> But if you don't generate fresh keys on every boot, the persistent
>> keys are mor exposed to other UEFI applications. Correct me if I'm
>> wrong, but I don't think UEFI variables are segregated between
>>
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> But if you don't generate fresh keys on every boot, the persistent
> keys are mor exposed to other UEFI applications. Correct me if I'm
> wrong, but I don't think UEFI variables are segregated between
> different UEFI
* joeyli:
> Yes, Matthew raised this concern at before. I modified patch to load
> private key in efi stub kernel, before ExitBootServices(), that means we
> don't need generate key-pair at every system boot. So, the above
> procedure of efi bootloader will only run one time.
But if you don't
* joeyli:
Yes, Matthew raised this concern at before. I modified patch to load
private key in efi stub kernel, before ExitBootServices(), that means we
don't need generate key-pair at every system boot. So, the above
procedure of efi bootloader will only run one time.
But if you don't
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
But if you don't generate fresh keys on every boot, the persistent
keys are mor exposed to other UEFI applications. Correct me if I'm
wrong, but I don't think UEFI variables are segregated between
different UEFI applications, so
* Matthew Garrett:
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
But if you don't generate fresh keys on every boot, the persistent
keys are mor exposed to other UEFI applications. Correct me if I'm
wrong, but I don't think UEFI variables are segregated between
different
On Sun, Sep 01, 2013 at 06:40:41PM +0200, Florian Weimer wrote:
* Matthew Garrett:
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
But if you don't generate fresh keys on every boot, the persistent
keys are mor exposed to other UEFI applications. Correct me if I'm
於 日，2013-09-01 於 18:40 +0200，Florian Weimer 提到：
* Matthew Garrett:
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
But if you don't generate fresh keys on every boot, the persistent
keys are mor exposed to other UEFI applications. Correct me if I'm
wrong, but I don't
於 四，2013-08-29 於 23:32 +0200，Pavel Machek 提到：
> Hi!
>
> > > >- Bootloader store the public key to EFI boottime variable by itself
> > > >- Bootloader put The private key to S4SignKey EFI variable for
> > > > forward to
> > > > kernel.
> > >
> > > Is the UEFI NVRAM really suited for
Hi!
> > >- Bootloader store the public key to EFI boottime variable by itself
> > >- Bootloader put The private key to S4SignKey EFI variable for forward
> > > to
> > > kernel.
> >
> > Is the UEFI NVRAM really suited for such regular updates?
> >
>
> Yes, Matthew raised this
Hi!
- Bootloader store the public key to EFI boottime variable by itself
- Bootloader put The private key to S4SignKey EFI variable for forward
to
kernel.
Is the UEFI NVRAM really suited for such regular updates?
Yes, Matthew raised this concern at before. I
於 四，2013-08-29 於 23:32 +0200，Pavel Machek 提到：
Hi!
- Bootloader store the public key to EFI boottime variable by itself
- Bootloader put The private key to S4SignKey EFI variable for
forward to
kernel.
Is the UEFI NVRAM really suited for such regular updates?
Hi Florian,
Thanks for your response.
於 三，2013-08-28 於 23:01 +0200，Florian Weimer 提到：
> * Chun-Yi Lee:
>
> > + EFI bootloader must generate RSA key-pair when system boot:
I should add more information on this sentence for mention need GenS4Key
runtime variable then re-generate key-pair.
* Chun-Yi Lee:
> + EFI bootloader must generate RSA key-pair when system boot:
>- Bootloader store the public key to EFI boottime variable by itself
>- Bootloader put The private key to S4SignKey EFI variable for forward to
> kernel.
Is the UEFI NVRAM really suited for such regular
* Chun-Yi Lee:
+ EFI bootloader must generate RSA key-pair when system boot:
- Bootloader store the public key to EFI boottime variable by itself
- Bootloader put The private key to S4SignKey EFI variable for forward to
kernel.
Is the UEFI NVRAM really suited for such regular
Hi Florian,
Thanks for your response.
於 三，2013-08-28 於 23:01 +0200，Florian Weimer 提到：
* Chun-Yi Lee:
+ EFI bootloader must generate RSA key-pair when system boot:
I should add more information on this sentence for mention need GenS4Key
runtime variable then re-generate key-pair.
Thanks!
Hi experts,
This patchset is the implementation for signature verification of hibernate
snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader
generate key-pair in UEFI secure boot environment, then pass it to kernel
for sign/verify S4 image.
Due to there have potential threat
Hi experts,
This patchset is the implementation for signature verification of hibernate
snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader
generate key-pair in UEFI secure boot environment, then pass it to kernel
for sign/verify S4 image.
Due to there have potential threat
20 matches
Mail list logo
