}
>
> +struct gcry_pk_spec *grub_crypto_pk_dsa;
> +struct gcry_pk_spec *grub_crypto_pk_ecdsa;
> +struct gcry_pk_spec *grub_crypto_pk_rsa;
> +
> void
> grub_crypto_hash (const gcry_md_spec_t *hash, void *out, const void *in,
> g
Y; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/*
> + * Given a hash value 'hval', of hash specification 'hash', perform
> + * the EMSA-PKCS1-v1_5 padding suitable for a key with modulus 'mod'
> + * (See RFC 8017 s 9.2)
> + */
> +gcry_err_code_t
> +grub_crypto_rsa_pad (gcry_mpi_t * hmpi, grub_uint8_t * hval,
> +const gcry_md_spec_t * hash, gcry_mpi_t mod);
> +
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
l_is_persistent (grub_dl_t mod)
> --
> 2.43.5
>
>
> _______________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
ules,
> +or sign them separately.
> +
> +
> @node Platform limitations
> @chapter Platform limitations
>
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>
>{
> diff --git a/util/mkimage.c b/util/mkimage.c
> index b46df2909..f5c59f563 100644
> --- a/util/mkimage.c
> +++ b/util/mkimage.c
> @@ -885,7 +885,7 @@ grub_install_generate_image (const char *dir, const char
> *prefix,
> char *memdisk_pat
ON_OEMTABLECREATORREV].arg,
> 0, 0);
>
>/* Load user tables */
>for (i = 0; i < argc; i++)
> @@ -758,7 +772,7 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int
> argc, char **args)
>acpi_tables = 0;
>
> #if defined (__i386__) || defined (__x86_6
As discussed in another thread, this breaks installing from x86 onto
removable disk for PPC Mac which is a supported workflow
Le ven. 8 nov. 2024, 14:13, Avnish Chouhan a écrit :
> This patch adds a check on install_device while installing grub for
> PowerPC.
> If install_device is not mentioned
Le lun. 14 oct. 2024, 00:13, Samuel Thibault
a écrit :
> Hello,
>
> For the debian installation CD, when using syslinux we can set an
> on-timeout entry which is different from the default entry. This is
> quite important because we want sighted people to be able to just press
> enter to get the
I think the entire series is bad if I understand it correctly. I ask the
same question again: are some files inaccessible with current code but
become accessible with these patches? Aka can I create a file that I can't
read with grub-fstest in the current code?
GRUB2 follows strict design that sam
Le lun. 21 oct. 2024, 06:49, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :
> On Fri, Oct 18, 2024 at 08:39:01PM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit
> :
> >
> > > From:
Le sam. 19 oct. 2024, 15:51, chench246 a écrit :
> From: chench246
>
> TPCM(Trusted Platform Control Module) is a Chinese standard and is
> compatible with TPM.
>
Before I review the patch: can you explain about compatibility. Of you day
that it's compatible with TPM, why doesn't normal TPM code
Le ven. 18 oct. 2024, 20:42, Neal Gompa a écrit :
> On Fri, Oct 18, 2024 at 1:39 PM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> >
> >
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit
> :
> >>
> >> From: Jeff Mahoney
> >
What if I put /boot and /boot/grub in different sub volumes? How do I set
variables then in order to correctly load additional modules from $prefix
and yet load correct kernels? This convoy is needed in order to load
several linuxes from the same btrfs (think installing v1 then making a
clone and u
Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit :
> From: Jeff Mahoney
>
> This patch adds the ability to specify a different root on a btrfs
> filesystem too boot from other than the default one.
>
Does it make available some files that are currentl y unavailable? Do you
have an example?
>
>
Reviewed-By: Vladimir Serbinenko phco...@gmail.com
Le mer. 16 oct. 2024, 08:22, Benjamin Herrenschmidt <
b...@kernel.crashing.org> a écrit :
> The calculation of the size of the table was incorrect (copy/pasta from
> grub_acpi_rsdt_find_table() I assume...). The entries are 64-bit long.
>
> This
Le mar. 15 oct. 2024, 08:24, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :
> On Thu, Oct 10, 2024 at 03:43:26PM GMT, Leo Sandoval wrote:
> > From: Paulo Flabiano Smorigo
> >
> > This patch makes grub look for its config file on efi where the app was
> > found. It was originally wri
Thank you for your effort but we already have nvme driver in the review
queue. See my email from 16th of May
Le dim. 13 oct. 2024, 22:38, a écrit :
> From: Mate Kukri
>
> It is based on existing SeaBIOS code, so the license is LGPLv3.
>
> Tested as a coreboot paload on the following targets:
>
Le mar. 8 oct. 2024, 10:23, Michael Chang via Grub-devel
a écrit :
> On Mon, Oct 07, 2024 at 12:20:55PM GMT, Leo Sandoval wrote:
> > From: Michael Chang
> >
> > Implement new net_bootp6 command for IPv6 network auto configuration via
> the
> > DHCPv6 protocol (RFC3315).
>
> This would have marke
Le mar. 8 oct. 2024, 09:53, Michael Chang via Grub-devel
a écrit :
> On Tue, Oct 08, 2024 at 08:07:17AM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Again, what do you try to achieve? Why aren't absolute paths enough?
>
> The absolute path does not align
Can you add a short comment in cmain why it's needed? It should mention
32-bit address truncation. The story in the commit message, on the other
hand, is way too long. It needs to be summarized with a link to full story.
Le lun. 7 oct. 2024, 21:19, Leo Sandoval a écrit :
> From: Paulo Flabiano S
This has a danger of rendering headless systems unbootable while waiting
for user input
Le lun. 7 oct. 2024, 21:19, Leo Sandoval a écrit :
> From: Peter Jones
>
> Signed-off-by: Peter Jones
> ---
> util/grub.d/00_header.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/util/grub.d
This increases the core size on i386-pc needlessly. And will increase even
more when we improve backtrace command. This needs to be a hook and loaded
together with normal. Also it needs to be cpu-agnostic
Le lun. 7 oct. 2024, 21:22, Leo Sandoval a écrit :
> From: Peter Jones
>
> ---
> grub-cor
LGTM
Reviewed-by: Vladimir Serbinenko phco...@gmail.com
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Peter Jones
>
> current gcc complains:
>
> grub-core/fs/btrfs.c: In function ‘grub_cmd_btrfs_info’:
> grub-core/fs/btrfs.c:2745:7: error: the comparison will always evaluate
>
Again, what do you try to achieve? Why aren't absolute paths enough?
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Michael Chang
>
> Signed-off-by: Michael Chang
> Signed-off-by: Robbie Harwood
> ---
> grub-core/osdep/linux/getroot.c | 7 +++
> grub-core/osdep/unix/config.c
Upstream uses "grub" for these commands. Rename to "grub2" is
distro-specific
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Peter Jones
>
> This needs to be hooked up to --program-transform=, but I haven't had
> time.
>
> Signed-off-by: Peter Jones
> ---
> docs/grub-dev.texi|
What do you try to achieve with this that can't be achieved with using full
path? We should avoid using hidden state for directory parsing. Solaris
GRUB legacy used it for ZFS and it was a mess.
Le lun. 7 oct. 2024, 21:22, Leo Sandoval a écrit :
> From: Michael Chang
>
> Signed-off-by: Michael
Leo Sandoval a écrit :
>
>
> On Mon, Sep 30, 2024 at 12:57 PM Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Why is it ppc-specific?
>>
>
> IBM wrote this patch so this is why this is ppc specific, but you are
> right, it can appl
Official stand of FSF and GNU project is that the correct name is
GNU/Linux. The only case where this could be justified is for non-GNU
variants like BusyBox distros or Android
Le lun. 30 sept. 2024, 20:48, Leo Sandoval a écrit :
> From: Peter Jones
>
> [rharwood: say it even less]
> ---
> gru
Using titles is broken concept and the only reason we support it in default
is backwards compatibility. Maybe it's better to restrict it to just IDs
Le lun. 30 sept. 2024, 20:48, Leo Sandoval a écrit :
> From: Peter Jones
>
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1026084
>
> Sig
This is already being reviewed in separate thread
Le lun. 30 sept. 2024, 20:46, Leo Sandoval a écrit :
> From: Peter Jones
>
> The BootLoaderSpec (BLS) defines a scheme where different bootloaders can
> share a format for boot items and a configuration directory that accepts
> these common conf
You seem to have forgotten the patch
Le lun. 30 sept. 2024, 22:07, Scottie Shore a
écrit :
> The +suffix format is described as a status flag here:
> https://gitlab.com/lvmteam/lvm2/-/blob/main/lib/format_text/flags.c#L238
>
> I've kept the match simple and in the style of the code around it. Th
This needs a detailed comment in quirks code as to why we disable video
mode.
Le lun. 30 sept. 2024, 20:47, Leo Sandoval a écrit :
> From: Paulo Flabiano Smorigo
>
> Should fix the problem in bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=973205
>
> Signed-off-by: Paulo Flabiano Smorig
Why is it ppc-specific?
Le lun. 30 sept. 2024, 20:49, Leo Sandoval a écrit :
> From: Mark Hamzy
>
> Add configuration support for serial terminal consoles. This will set
> the maximum screen size so that text is not overwritten.
>
> Signed-off-by: Mark Hamzy
> Signed-off-by: Robbie Harwood
>
Reviewed-by: phco...@gmail.com
Le jeu. 29 août 2024, 14:07, Rasmus Villemoes via Grub-devel <
grub-devel@gnu.org> a écrit :
> Unlike files accessed via a normal file system, the file->read_hook is
> not honoured when using blocklist notation.
>
> This means that when trying to use a dedicated, 1K
The code for auto detect of root device on EFI is
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/kern/efi/init.c#n130
. It will have no problem detecting right device even if there are similar
devices. The only case I know of, where it's unreliable is if partition
module for partition in
On Thu, Sep 5, 2024 at 3:53 PM Daniel Kiper wrote:
>
> On Tue, Sep 03, 2024 at 08:29:30PM +0300, Vladimir Serbinenko wrote:
> > We currently use an old version of libcrypt which
> > results in us having fewer ciphers and missing on many
> > other improvements.
> >
> > Signed-off-by: Vladimir Serbi
>
>
>
> And main argument: I'm aware of one example when "EFI" is hard-coded in
> signed secure boot GRUB binary. Debian has 4 signed GRUB binaries. All they
> are generated here:
> https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ .
> One of them, grubx64.efi is created using "g
Le sam. 7 sept. 2024, 00:51, Pascal Hambourg a
écrit :
> On 06/09/2024 at 15:15, Askar Safin wrote:
> >
> > While testing this script I noticed this: if I boot from disk (i. e.
> > using "-drive" Qemu option), then "grub.cfg" is read from ESP, i. e.
> > FAT. But if I boot from CD (i. e. using "-c
Reviewed-by: phco...@gmail.com
Le ven. 6 sept. 2024, 04:38, Glenn Washburn a
écrit :
> Signed-off-by: Glenn Washburn
> ---
> docs/grub.texi | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 63e796a3a738..e6e5efa05e6
v2: Changed how I fix module search: instead of matching alignment,
compute the module position explicitly
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Reviewed-by: phco...@gmail.com
Le mar. 3 sept. 2024, 11:02, Frediano Ziglio via Grub-devel <
grub-devel@gnu.org> a écrit :
> The function called is grub_utf8_to_utf16.
>
> Signed-off-by: Frediano Ziglio
> ---
> grub-core/loader/efi/linux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: phco...@gmail.com
Le mar. 3 sept. 2024, 11:02, Frediano Ziglio via Grub-devel <
grub-devel@gnu.org> a écrit :
> Used also in other assembly files.
> They are single 64-bit values.
>
> Signed-off-by: Frediano Ziglio
> ---
> grub-core/lib/x86_64/relocator_asm.S | 12 ++--
> 1
This also sets a variable at it's end. Can you adjust the commit message?
Or even split it?
Le mar. 3 sept. 2024, 11:02, Frediano Ziglio via Grub-devel <
grub-devel@gnu.org> a écrit :
> Signed-off-by: Frediano Ziglio
> ---
> grub-core/loader/efi/linux.c | 5 +++--
> 1 file changed, 3 insertions
This series of patches fixes compilation and running on Yeeloong 2F
with new GCC.
Clang is not supported as it fails to compile for mips3 architecture
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu
he quick feedback!
>
> - Andrew
>
> On Sat, Aug 17, 2024 at 9:03 AM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> > No, it's license-incompatible. Please don't use that code.
> >
> > Le sam. 17 août 2024, 16:44, Andrew Hamilton a
&
No, it's license-incompatible. Please don't use that code.
Le sam. 17 août 2024, 16:44, Andrew Hamilton a écrit :
> Hello,
>
> I'm thinking to try to address bug 63894 (grub_datetime2unixtime()
> still has the year 2038 problem):
> https://savannah.gnu.org/bugs/?63894
>
> I confirmed the issue i
Le lun. 1 juil. 2024, 17:12, Thomas Schmitt via Grub-devel <
grub-devel@gnu.org> a écrit :
> Hi,
>
> i found a wrong word in an error message of grub-core/fs/iso9660.c
> function grub_iso9660_uuid():
>
> grub_error (GRUB_ERR_BAD_NUMBER, "no creation date in filesystem
> to generate UUID")
Did you try:
insmod regexp
for x in (*); do
done
Just trying to understand the problem
Le dim. 30 juin 2024, 19:26, Denis 'GNUtoo' Carikli <
gnu...@cyberdimension.org> a écrit :
> Hi,
>
> The problem we try to solve with --set=VARNAME in ls.
>
otocols[j]);
> }
>
> + if (protocols)
> + grub_efi_free_pool (protocols);
> }
>
> + grub_free (handles);
> +
>return 0;
> }
>
> --
> 2.45.2
>
>
> ___
> Grub-devel mailing list
> Grub-devel@g
> + if (protector == NULL || protector->name == NULL || grub_strlen
> (protector->name) == 0)
> +return GRUB_ERR_BAD_ARGUMENT;
> +
Here and in the other places you miss grub_error. Note that the
message in such technical cases should be left untranslated (no N_
mark).
> + if (protector == N
oller, controller_handle,
> +driver_image_handle, remaining_device_path, recursive);
> +}
> +
> void *
> grub_efi_open_protocol (grub_efi_handle_t handle,
> grub_guid_t *protocol,
> diff --git a/include/grub/efi/disk.h b/i
Should we add a random wait to avoid all the machines retrying au the same
time?
Le mer. 26 juin 2024, 13:57, Mukesh Kumar Chaurasiya
a écrit :
> Sometimes, when booting from a very busy SAN, the access to the
> disk can fail and then GRUB will eventually drop to GRUB prompt.
> This scenario is
Concept of ofpathname is clear: return OF path to a given device or NULL if
none. Returning anything else is a bug even if it ends up helping you
somewhere.
Le jeu. 20 juin 2024, 12:45, avnish a écrit :
> Hi Vladimir,
>
> We have implemented this code to enable the ieee1275 hint for grub. We
> h
tcmd_t cmd_fdtdump;
>
> GRUB_MOD_INIT (fdt)
> {
> + fw_fdt = grub_efi_get_firmware_fdt();
> +
> + cmd_fdtdump =
> +grub_register_extcmd ("fdtdump", grub_cmd_fdtdump, 0,
> + N_("[-p] [--set variable]"),
> + N_
ispose.
> But there must be some better way to test a utility built from git
> independenly of systemwide directories.
>
>
> Vladimir 'phcoder' Serbinenko wrote:
> > Set pkgdatadir environment variable
>
> Ahum ...
> rm /usr/local/share/grub
> pkgdatadi
Set pkgdatadir environment variable
Le ven. 14 juin 2024, 16:17, Thomas Schmitt via Grub-devel <
grub-devel@gnu.org> a écrit :
> Hi,
>
> on occasion of
> https://savannah.gnu.org/bugs/index.php?65880
> "heap-buffer-overflow in grub-mkrescue.c"
> i try to get grub-mkrescue running from git.
>
Le ven. 7 juin 2024, 10:34, avnish a écrit :
> On 2024-06-06 21:04, Vladimir 'phcoder' Serbinenko wrote:
> > 2 problems: * How does dm device ends up on ofpathname? It should be
> > handled by grub internal logic in most cases and not end up in
> > of-specif
2 problems:
* How does dm device ends up on ofpathname? It should be handled by grub
internal logic in most cases and not end up in of-specific paths
* Why not use existing devmapper functions already present in codebase?
Le jeu. 6 juin 2024, 14:40, Avnish Chouhan a écrit :
> This patch enables
.8c5660825 100644
> --- a/util/mkimage.c
> +++ b/util/mkimage.c
> @@ -886,7 +886,8 @@ grub_install_generate_image (const char *dir, const char
> *prefix,
> size_t npubkeys, char *config_path,
> const struct grub_install_image_target_desc
> *image_target,
> int note, grub_compression_t comp, const char
> *dtb_path,
> -const char *sbat_path, int disable_shim_lock)
> +const char *sbat_path, int disable_shim_lock,
> +int disable_cli)
> {
>char *kernel_img, *core_img;
>size_t total_module_size, core_size;
> @@ -948,6 +949,9 @@ grub_install_generate_image (const char *dir, const char
> *prefix,
>if (disable_shim_lock)
> total_module_size += sizeof (struct grub_module_header);
>
> + if (disable_cli)
> +total_module_size += sizeof (struct grub_module_header);
> +
>if (config_path)
> {
>config_size = ALIGN_ADDR (grub_util_get_image_size (config_path) + 1);
> @@ -1094,6 +1098,16 @@ grub_install_generate_image (const char *dir, const
> char *prefix,
>offset += sizeof (*header);
> }
>
> + if (disable_cli)
> +{
> + struct grub_module_header *header;
> +
> + header = (struct grub_module_header *) (kernel_img + offset);
> + header->type = grub_host_to_target32 (OBJ_TYPE_DISABLE_CLI);
> + header->size = grub_host_to_target32 (sizeof (*header));
> + offset += sizeof (*header);
> +}
> +
>if (config_path)
> {
>struct grub_module_header *header;
> --
> 2.27.0
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Sorry, sent wrong commit. Will resend in next version
Le mar. 28 mai 2024, 08:49, Gary Lin a écrit :
> On Fri, May 24, 2024 at 08:30:06PM +0300, Vladimir Serbinenko wrote:
> > ---
> > .../lib/libgcrypt-patches/02_keccak_sse.diff | 19 +++
> > 1 file changed, 19 insertions(+)
>
Le lun. 27 mai 2024, 16:38, Avnish Chouhan a écrit :
> This patch adds a check on install_device while installing grub for
> PowerPC.
> If install_device is not mentioned in grub2-install, the error will be
> thrown.
> Running grub2-install on PowerPC without the install_device may
> result in bo
void *source_buffer,
> + grub_efi_uintn_t source_size,
> + grub_efi_handle_t *image_handle);
> +
> + grub_efi_status_t (__grub_efi_api *start_image) (grub_efi_handle_t
> image_handle,
> +
> Future work:
> - Completely disable non-NX compatible loaders when heap allocation are
> marked NX.
> This should be independent from the NX-enforcement flag and Secure Boot
> status.
> (Note that this is non-crtitical for security, as non-UEFI/Linux loaders
> are disabled
>by SB lockd
nd
> trampolines\n",
> mod->name);
> + if (tgaddr < (grub_addr_t)mod->base ||
> + tgsz > (grub_addr_t)-1 - tgaddr ||
> + tgaddr + tgsz > (grub_addr_t)mod->base + mod->sz)
> + return grub_error (
> - tsize += ALIGN_UP (tramp, GRUB_ARCH_DL_TRAMP_ALIGN);
> - if (talign < GRUB_ARCH_DL_TRAMP_ALIGN)
> -talign = GRUB_ARCH_DL_TRAMP_ALIGN;
> - tsize += ALIGN_UP (got, GRUB_ARCH_DL_GOT_ALIGN);
> - if (talign < GRUB_ARCH_DL_GOT_ALIGN)
> -talign = GRUB_ARCH_DL_GOT_ALIGN;
> + tramp_align =
PE_OHDR (o32, o64, header_size) = grub_host_to_target32 (header_size);
> PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32
> (layout.start_address);
> PE_OHDR (o32, o64, image_base) = 0;
> --
> 2.39.2
>
>
> __________
Ehdr *e, const Elf_Shdr *s)
> +{
> + Elf_Shdr *str_s;
> + const char *str;
> +
> + str_s = (Elf_Shdr *) ((char *) e + e->e_shoff + e->e_shstrndx *
> e->e_shentsize);
> + str = (char *) e + str_s->sh_offset;
> +
> + return str + s->sh_name;
> +}
> +
&g
grub_uint64_t *attrs);
> +grub_err_t EXPORT_FUNC(grub_update_mem_attrs) (grub_addr_t addr,
> + grub_size_t size,
> + grub_uint64_t set_attrs,
> + grub_uint64_t clear_attrs);
> +#else /* !GRUB_MACHINE_EFI */
> +static inline grub_err_t
> +grub_get_mem_attrs (grub_addr_t addr __attribute__((__unused__)),
> + grub_size_t size __attribute__((__unused__)),
> + grub_uint64_t *attrs __attribute__((__unused__)))
> +{
> + return GRUB_ERR_NONE;
> +}
> +
> +static inline grub_err_t
> +grub_update_mem_attrs (grub_addr_t addr __attribute__((__unused__)),
> + grub_size_t size __attribute__((__unused__)),
> + grub_uint64_t set_attrs __attribute__((__unused__)),
> + grub_uint64_t clear_attrs __attribute__((__unused__)))
> +{
> + return GRUB_ERR_NONE;
> +}
> +#endif /* GRUB_MACHINE_EFI */
> +
> void grub_mm_check_real (const char *file, int line);
> #define grub_mm_check() grub_mm_check_real (GRUB_FILE, __LINE__);
>
> --
> 2.39.2
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
What happens when 2 sections with the same NX and WR attributes follow
each other? Do we need to split them per page? How often do we
needlessly split in the current codebase?
> to dump into the ELF section header, which is often pretty useless.
I think this is not true. It's not useless, just d
ture[GRUB_PE32_SIGNATURE_SIZE];
> + struct grub_pe32_coff_header coff_header;
> + struct grub_pe64_optional_header optional_header;
> +};
> +
> struct grub_pe32_fixup_block
> {
>grub_uint32_t page_rva;
> --
> 2.39.2
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
, s->sh_addralign) + s->sh_size;
>if (talign < s->sh_addralign)
> talign = s->sh_addralign;
> --
> 2.39.2
>
>
> ___________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mail
39.2
>
>
> ___________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
E_USED)) = #name
> --
> 2.39.2
>
>
> ___________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
I think at least AUTHORS and COPYING should be included. Rest is for the
ease of update in the future.
Le mar. 21 mai 2024, 10:32, Gary Lin a écrit :
> Hi Vladimir,
>
> Originally, there are only cipher, mpi, and src in the libgcrypt
> directory, but the unnecessary stuff, e.g. AUTHORS, COPYING,
Le ven. 17 mai 2024, 21:26, Gao Xiang a
écrit :
> Hi Vladimir,
>
> On 2024/5/18 00:38, Vladimir 'phcoder' Serbinenko wrote:
> > I think that given that align is a non zero const we can trust it.
>
> From the EROFS specific cases, they are always non-zero values
I think that given that align is a non zero const we can trust it.
Le ven. 17 mai 2024, 15:56, Gao Xiang a
écrit :
> The following EROFS patch will use this helper to handle overflow
> ALIGN_UP() cases.
>
> Signed-off-by: Gao Xiang
> ---
> include/grub/safemath.h | 16
> 1 fil
Le ven. 17 mai 2024, 14:15, Daniel Kiper a écrit :
> Why is this patch needed? Should not we disable SSE using compiler flags?
>
We do but the code in question uses SSE on every x64 platform. So we need
to disable this acceleration. At least for now. If we want to enable SSE
(maybe we should) we
This series of patches upgrades to libgcrypt 1.10.3
First one just imports libgcrypt tarball as-is
Second one updates import script
Third one add a small adjustments to make it work with GRUB x64
--
Regards
Vladimir 'phcoder' Serbinenko
___
Hey. Can you describe what exactly are you trying to solve?
Le ven. 3 mai 2024, 17:46, Mathieu Mirmont a écrit :
> It isn't an error for an elf executable to be lacking a section header
> table. In this case we should just be returning shnum = 0.
>
> According to the elf(5) manual page:
> "
> e_
you suggesting that I should remove the error code conversion here?
>
Yes. Since 2012 (commit bfb320c644e2a3ea463f8bbf72507b2f7b7132d0) this
logic is no longer necessary. ext2 has this logic back from 2009 and
probably should be removed by now
>
> All the other suggestions are
Generally looks good. Few comments. I have missed part of discussion, so
point me to relevant parts of it if I miss something that's already been
discussed
Le mer. 24 avr. 2024, 14:31, Yifan Zhao a écrit :
De qq,
> + struct grub_erofs_super *sb = &node->data->sb;
> +
> + return (grub_le_to_cpu
Not a full review. Please don't put new functions like strnlen into kernel
of they are useful only to one module. Kernel size is restricted to a
different degree on some platforms
Le mer. 24 avr. 2024, 14:31, Yifan Zhao a écrit :
> EROFS [1] is a lightweight read-only filesystem designed for per
Selecting by title is deprecated and kept only for compatibility. Please
use id instead
Le lun. 22 avr. 2024, 17:56, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> a écrit :
> From: Peter Jones
>
> Resolves: rhbz#1026084
>
> Signed-off-by: Peter Jones
> ---
> grub-core/normal/me
I'm unsure whether an id starting with a numeral should be considered valid
at all. Variable named 0x would be incorrect
Le lun. 22 avr. 2024, 17:57, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> a écrit :
> From: Peter Jones
>
> Currently if grub_strtoul(saved_entry_value, NULL,
LGTM. Reviewed-by: Vladimir Serbinenko
Le mar. 9 avr. 2024, 20:56, Daniel Kiper a écrit :
> Otherwise the GRUB cannot start when stack protector is enabled on EFI
> platforms.
>
> Signed-off-by: Daniel Kiper
> ---
> include/grub/stack_protector.h | 4
> 1 file changed, 4 insertions(+)
>
>
_
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
eply but I was busy with other stuff...
>
> On Fri, Mar 15, 2024 at 09:43:22PM +0300, Vladimir 'phcoder' Serbinenko
> wrote:
> > stack protector needs symbols with just one underscore in C
> > name unlike unix variant that needs double underscore.
> > Supply bot
On Sat, Feb 17, 2024 at 12:39 AM Jon DeVree wrote:
>
> On Thu, Feb 15, 2024 at 20:33:13 +0300, Vladimir 'phcoder' Serbinenko wrote:
> > Is the pointer guaranteed to be aligned? If not you have to use unaligned
> > access.
>
> I don't know what alignment gua
fmap (flash map) is a partition table used by coreboot. Support it in
order to retrieve the files in non-default partition
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-Implement-fmap-support.patch
Description: B
This is useful to check zfs-bootfs command.
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-grub-fstest-Add-a-new-command-zfs-bootfs.patch
Description: Binary data
___
Grub-devel mailing list
Grub-dev
With FMAP and non-continuous SPI old way of reading CBFS pointer
is no longer reliable. Hence use new lbio tags to detect the correct
cbfs layout
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-Improve-cbfs-detection.patch
Description: B
With some coreboot configs setting a byte to a magic value
changes behaviour on next boot. Setting bit-by-bit is
possible but not convenient. Add cmosread and cmoswrite for
convenience.
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-Add-commands-f
CMOS actually exists on most EFI platforms and in some cases used to
store useful data that makes it useful for GRUB to read/write it
As for datetime keep using EFI API and not CMOS
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-Enable-cmos-on-x86
No alignment is guaranteed and in fact on my ia64 sapic is aligned
to 4 bytes instead of 8 and causes a trap. It affects only rarely used
lsacpi command and so went unnoticed.
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-acpi-Mark-MADT-
Current code in some codepaths neither discards nor reports
errors. Properly surface the error
While on it split 2 cases of unrelated variables both named err.
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-MULTIBOOT-Fix-handling-of-errors-in-b
stack protector needs symbols with just one underscore in C
name unlike unix variant that needs double underscore.
Supply both symbols for simplicity
Signed-off-by: Vladimir Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
0001-STACK_PROTECTOR-Support-symbols-emitted-by-windo
On Mon, May 8, 2023 at 5:01 PM Avnish Chouhan wrote:
>
> From: Diego Domingos
>
> This patch enables the device mapper discovery on ofpath.c. Currently,
> when we are dealing with a device like /dev/dm-* the ofpath returns null
> since there is no function implemented to handle this case.
Why is
Not a full review. Just one blocking problem
>
> }
> + case MULTIBOOT_LOAD_TYPE_PE:
> + grub_fatal ("Unsupported load type: %u\n", mld.load_type);
> + default:
> +/* should be impossible */
> +grub_fatal ("Unknown load type: %u\n", mld.load_type);
>
Don't use grub_fatal for th
Verifying after decompression is a bad security practice. It relies on
decompression having no security holes. Given how complex decompression is,
this is almost guaranteed to be false.
Le mer. 13 mars 2024, 18:08, Ross Lagerwall via Grub-devel <
grub-devel@gnu.org> a écrit :
> It is convenient a
_
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
1 - 100 of 1571 matches
Mail list logo
