On 6/1/20 8:49 PM, Andy Lutomirski wrote:
>
>
>> On Jun 1, 2020, at 5:14 PM, Daniel P. Smith
>> wrote:
>>
>> On 6/1/20 3:39 PM, Andy Lutomirski wrote:
> .
>>
>> In other words, the log for the relaunch to attest what is currently
>> running is really no less useful than using the first lau
> On Jun 1, 2020, at 5:14 PM, Daniel P. Smith
> wrote:
>
> On 6/1/20 3:39 PM, Andy Lutomirski wrote:
.
>
> In other words, the log for the relaunch to attest what is currently
> running is really no less useful than using the first launch log to
> attest to the what was running in the f
On 6/1/20 3:39 PM, Andy Lutomirski wrote:
>
>> On Jun 1, 2020, at 10:56 AM, Daniel P. Smith
>> wrote:
>>
>> On 6/1/20 12:51 PM, Andy Lutomirski wrote:
On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
wrote:
On 5/7/20 7:06 AM, Daniel Kiper wrote:
> Hi Łukasz,
>
> O
> On Jun 1, 2020, at 10:56 AM, Daniel P. Smith
> wrote:
>
> On 6/1/20 12:51 PM, Andy Lutomirski wrote:
>>> On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
>>> wrote:
>>>
>>> On 5/7/20 7:06 AM, Daniel Kiper wrote:
Hi Łukasz,
On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawr
Adjust the interface of `grub_efi_mm_add_regions ()` to take a set of
`GRUB_MM_REGION_*` flags, which most notably is currently only the
`CONSECUTVE` flag. This allows us to set the function up as callback for
the memory subsystem and have it call out to us in case there's not
enough pages availabl
Currently, all platforms will set up their heap on initialization of the
platform code. While this works mostly fine, it poses some limitations
on memory management on us. Most notably, allocating big chunks of
memory in the gigabyte range would require us to pre-request this many
bytes from the fi
In preparation of support for runtime-allocating additional memory
region, this patch extracts the function to retrieve the EFI memory map
and add a subset of it to GRUB's own memory regions.
Note that this commit also changes how many bytes we request by default.
Previously, we would've tried to
Hi,
as you may be aware, LUKS2 currently doesn't support the Argon2 key
derival function (KDF). While the implementation itself isn't much of a
problem in theory, one issue we currently have is that Argon2 is a
memory-safe KDF and thus requires huge chunks of memory. The memory
management subsyste
On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
wrote:
>
> On 5/7/20 7:06 AM, Daniel Kiper wrote:
> > Hi Łukasz,
> >
> > On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
> >> On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:
>
> ...
>
> >> In OS-MLE table there is a buffer for
On Fri, 29 May 2020 13:27:35 +0200
Daniel Kiper wrote:
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I
> discussed this proposal with Ross and Daniel S. So, the idea went
> through initial sanitization. Now
On 6/1/20 1:56 PM, Daniel P. Smith wrote:
> On 6/1/20 12:51 PM, Andy Lutomirski wrote:
>> On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
>> wrote:
>>>
>>> On 5/7/20 7:06 AM, Daniel Kiper wrote:
Hi Łukasz,
On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
> On Tue,
On 6/1/20 12:51 PM, Andy Lutomirski wrote:
> On Mon, Jun 1, 2020 at 8:33 AM Daniel P. Smith
> wrote:
>>
>> On 5/7/20 7:06 AM, Daniel Kiper wrote:
>>> Hi Łukasz,
>>>
>>> On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:
>>
>
On 5/7/20 7:06 AM, Daniel Kiper wrote:
> Hi Łukasz,
>
> On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
>> On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:
...
>> In OS-MLE table there is a buffer for TPM event log, however I see that
>> you are not using it, but instead a
On 5/22/20 9:24 AM, Krystian Hebel wrote:
>
> On 05.05.2020 01:21, Daniel Kiper wrote:
>> +static grub_err_t
>> +init_txt_heap (struct grub_slaunch_params *slparams, struct
>> grub_txt_acm_header *sinit)
>> +{
>> + grub_uint8_t *txt_heap;
>> + grub_uint32_t os_sinit_data_ver, sinit_caps;
>> + g
When a file is verified, the entire contents of the verified file are
loaded in to memory and retained until the file handle is closed. A
consequence of this is that opening a loopback image can incur a
significant memory cost.
As loopback devices are just another disk implementation, don't treat
On Fri, May 29, 2020 at 01:27:35PM +0200, Daniel Kiper wrote:
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
> sa
On Fri, May 29, 2020 at 10:11:40AM -0700, Andy Lutomirski wrote:
> > On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
> >
> > Hey,
> >
> > Below you can find my rough idea of the bootloader log format which is
> > generic thing but initially will be used for TrenchBoot work. I discussed
> > this p
17 matches
Mail list logo
