Linux kernel from 4.11 has secure_boot member as part of linux_kernel_params.
Currently, GRUB does not populate it, so the kernel reports
"Secure boot could not be determined" on boot. We can populate it in EFI mode,
so the kernel "knows" the status.
Signed-off-by: Ignat Korch
Signed-off-by: Ignat Korchagin
---
grub-core/kern/efi/efi.c | 13 +++--
include/grub/efi/efi.h | 4
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
index 708581fcb..5f7d1478f 100644
--- a/grub-core/kern/efi/efi.c
Reworked the logic to more closely resemble the one in the Linux efistub
implementation:
* added checking for "MokSBState" variable
* added a function to efi core to read EFI variables with their attributes,
because "MokSBState" handling requires taking attributes
Linux kernel from 4.11 has secure_boot member as part of linux_kernel_params.
Currently, GRUB does not populate it, so the kernel reports
"Secure boot could not be determined" on boot. We can populate it in EFI mode,
so the kernel "knows" the status.
Signed-off-by: Ignat Korch
Signed-off-by: Ignat Korchagin
---
grub-core/loader/multiboot_elfxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/loader/multiboot_elfxx.c
b/grub-core/loader/multiboot_elfxx.c
index ae36d9d49..70cd1db51 100644
--- a/grub-core/loader/multiboot_elfxx.c
+++ b/grub
Thank you very much for your effort!
Any reasons you haven't considered my bugfix for the release?
http://lists.gnu.org/archive/html/grub-devel/2016-12/msg9.html
On Wed, Apr 26, 2017 at 12:27 PM, Vladimir 'phcoder' Serbinenko
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hel
I tried to submit a patch some time ago, where you can get SecureBoot and
SetupMode variables from GRUB shell and config file:
http://lists.gnu.org/archive/html/grub-devel/2016-01/msg00078.html
It was abandoned for some reason.
Also, I think recent patches proposed by Matthew Garrett also allow t
not see a better approach
As for other concerns I commented in my previous reply to the patch.
Thank you.
On Mon, Dec 12, 2016 at 1:20 PM, Daniel Kiper wrote:
> Hi Ignat,
>
> On Sun, Dec 11, 2016 at 02:51:00PM +, Ignat Korchagin wrote:
> > General thoughts:
> > Just a remi
ect.
- ...
Sorry for the noise, but this is something which came up working on this...
Specific patch comments below.
On Sat, Dec 10, 2016 at 5:59 PM, Andrei Borzenkov wrote:
> 02.12.2016 19:58, Ignat Korchagin пишет:
>> According to RFC 4880 5.2.3 only "Signature Creation Time&
> One nitpick, may I add your SOB (Signed-off-by) here?
Sorry, somehow I missed it this time (probably forgot to specify the
git option).
Yes, please add it.
On Mon, Dec 5, 2016 at 3:24 PM, Daniel Kiper wrote:
> On Fri, Dec 02, 2016 at 04:58:39PM +, Ignat Korchagin wrote:
>> Acco
According to RFC 4880 5.2.3 only "Signature Creation Time" subpacket
"MUST" be present in the hashed area. All other subpacket types may be present
either in hashed or unhashed areas. Currently GRUB assumes, that the "Issuer"
subpacket is in unhashed area (by default put there by gpg tool), but oth
On Mon, Nov 21, 2016 at 6:56 PM, Jon McCune wrote:
> On Mon, Nov 21, 2016 at 6:45 AM, Daniel Kiper wrote:
>>
>> On Fri, Nov 18, 2016 at 12:00:08PM +, Ignat Korchagin wrote:
>> > Reposting this, as requested by Daniel and rebasing on current tree.
>> >
On Mon, Nov 21, 2016 at 3:45 PM, Daniel Kiper wrote:
> On Fri, Nov 18, 2016 at 12:00:08PM +0000, Ignat Korchagin wrote:
>> Reposting this, as requested by Daniel and rebasing on current tree.
>>
>> Currently GRUB2 verify logic searches PGP keyid only in unhashed subpackets
verified,
because this package puts keyid in hashed subpackets and GRUB code never
initializes the keyid variable, therefore is not able to find "verification
key" with id 0x0.
Signed-off-by: Ignat Korchagin
---
grub-core/commands/verify.c | 115 +
A little busy now, but will try to send the patch this week.
On Tue, Nov 15, 2016 at 12:42 PM, Daniel Kiper wrote:
> On Sun, Nov 13, 2016 at 12:18:05PM +0300, Andrei Borzenkov wrote:
> > 10.11.2016 16:50, Daniel Kiper ??:
> > > On Thu, Apr 28, 2016 at 10:32:13PM +010
Is this going to 2.02? I think it should, because it is a bug.
On Thu, Apr 21, 2016 at 5:54 PM, Ignat Korchagin wrote:
> Best of both worlds: I left the READBUF_SIZE as is for the rest of the code,
> but rather reallocate the buffer with appropriate length for subpackets
> spe
Best of both worlds: I left the READBUF_SIZE as is for the rest of the code,
but rather reallocate the buffer with appropriate length for subpackets
specifically. Hashing is outside of the keyid search function, so the name is
good this time.
Still did not get your response about PGP private te
And http://lists.gnu.org/archive/html/grub-devel/2016-04/msg00040.html
On Wed, Apr 20, 2016 at 11:11 AM, Andrei Borzenkov wrote:
> http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00294.html
>
> On Wed, Apr 20, 2016 at 4:59 AM, Charles Duffy wrote:
>> Howdy --
>>
>> When trying to valida
available?
On Sun, Apr 10, 2016 at 7:34 PM, Ignat Korchagin wrote:
>> TBH I still think that simply setting READBUF_SIZE to 64K is the simplest
>> solution.
>
> I would agree, but I was just a little concerned about allocating
> large buffer. I'm not sure whether GRUB i
> TBH I still think that simply setting READBUF_SIZE to 64K is the simplest
> solution.
I would agree, but I was just a little concerned about allocating
large buffer. I'm not sure whether GRUB is considered to be able to
run on very resource constrained environments and it seemed that
per-subpac
Implemented as a separate function which should process arbitrary length data.
As for tests, it seems that the easiest way is to add this signature to
tests/file_filter. Not sure how should I send you the patch with binary data
though.
diff --git a/grub-core/commands/verify.c b/grub-core/comman
be longer than READBUF_SIZE, the signature
check will fail as well.
On Wed, Mar 30, 2016 at 5:44 AM, Andrei Borzenkov wrote:
>
> 29.03.2016 22:02, Ignat Korchagin пишет:
> > Currently GRUB2 verify logic searches PGP keyid only in unhashed subpackets
> > of PGP signature p
Currently GRUB2 verify logic searches PGP keyid only in unhashed subpackets of
PGP signature packet. As a result, signatures generated with GoLang openpgp
package (https://godoc.org/golang.org/x/crypto/openpgp) could not be verified,
because this package puts keyid in hashed subpackets and GRUB
+1 For the MSS option
I've actually submitted similar patch a while ago
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00120.html
Didn't have time to finish it at first, but then decided to back off until
window scaling gets merged to follow generic way of declaring TCP options.
But this
Hi. Are we still considering this?
On Mon, Dec 14, 2015 at 11:17 AM, Ignat Korchagin
wrote:
> Sorry, pasted wrong file. Here is the correct one:
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 0cc40bb..aa7b927 100644
> --- a/grub-core/Makefile.c
bug
in module?)"));
+ goto err;
+ }
+
+ if (efi_type != EFI_VAR_DUMP)
+{
+ if (state[1].set)
+status = grub_env_set (state[1].arg, env_var);
+ else
+{
+ grub_printf ("%s\n", (const char *)env_var);
+ status = GRUB_ERR_NONE;
+
> Assuming uint8 remains - should not you check that variable size is exactly 1
> byte in this case?
There are reports of a buggy firmware returning 4 bytes size for uint8
variables, however did not encounter them myself.
> Do we really need unit8 at all? "hex" already provides exactly the same
Is this still considered?
On Thu, Dec 3, 2015 at 5:19 PM, Ignat Korchagin wrote:
>> This should be grub_strcmp everywhere, there is no reason to use
>> grub_strncmp.
> Yes, you are right. Please, find updated patch below
>
>> I believe it should be "content"
> This should be grub_strcmp everywhere, there is no reason to use grub_strncmp.
Yes, you are right. Please, find updated patch below
> I believe it should be "content" (without final `s') but English is not native
Mine not as well, but asked my native colleagues and they confirmed
"contents". Als
char *)env_var);
+ status = GRUB_ERR_NONE;
+}
+}
+
+err:
+
+ if (env_var)
+grub_free (env_var);
+
+ if (efi_var)
+grub_free (efi_var);
+
+ return status;
+}
+
+static grub_extcmd_t cmd = NULL;
+
+GRUB_MOD_INIT (efivar)
+{
+ cmd = grub_register_extcmd ("get_e
tcmd ("get_efivar", grub_cmd_get_efi_var, 0,
N_("[-f FORMAT] [-s ENV_VAR] EFI_VAR"),
+ N_("Read EFI variable and print it or save its contents to
environment variable."), options);
+}
+
+GRUB_MOD_FINI (efivar)
+{
+ if (cmd)
+grub_unregister_extcmd (cmd);
+}
diff --g
iables now are using ASCII for string data.
On Fri, Nov 27, 2015 at 2:07 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 14.11.2015 05:03, Andrei Borzenkov wrote:
>> 13.11.2015 22:42, Ignat Korchagin пишет:
>>>>>> +static enum efi_var_type
>>>
r", grub_cmd_get_efi_var, 0,
N_("[-f FORMAT] [-s ENV_VAR] EFI_VAR"),
+ N_("Read EFI variable and print it or save its contents to
environment variable."), options);
+}
+
+GRUB_MOD_FINI (efivar)
+{
+ if (cmd)
+grub_unregister_extcmd (cmd);
+}
di
On Fri, Nov 13, 2015 at 11:34 AM, Ignat Korchagin wrote:
> On Wed, Nov 11, 2015 at 10:09 AM, Andrei Borzenkov
> wrote:
>> 06.11.2015 05:00, Ignat Korchagin пишет:
>>>
>>> Actually, I submitted similar patch recently as well. It provides read
>>> function
On Wed, Nov 11, 2015 at 10:09 AM, Andrei Borzenkov wrote:
> 06.11.2015 05:00, Ignat Korchagin пишет:
>>
>> Actually, I submitted similar patch recently as well. It provides read
>> function for variables and accepts a hint on how to process them. The
>> origi
Actually, I submitted similar patch recently as well. It provides read
function for variables and accepts a hint on how to process them. The
original patch is here:
https://lists.gnu.org/archive/html/grub-devel/2015-09/msg00043.html.
Probably, I forgot to enable plain-text mode, so it got there as
Currently, GRUB neither parses nor announces TCP MSS option. According
to RFC 879 and its successors if the MSS option is not present the
default TCP segment size is 536.
That is the exact amount received for every TCP segment for an HTTP
download (tested with Debian Linux), that is the peer TCP st
Would like to add a command for reading EFI variables from command line or
config files to make following scenario possible in grub.cfg:
# check whether Secure Boot is enabled
get_efivar -t uint8 SecureBoot efi_secure_boot
if [ $efi_secure_boot = 1 ]; then
# secure boot is enabled, boot our secur
38 matches
Mail list logo
