openslx-ng/ipxe.git/src/core/settings.c, branch v0.9.7

[settings] Allow store_setting() to access the root settings block

2009-02-17T11:57:31+00:00

[settings] Handle errors in fetchf_uristring()

2009-02-12T09:16:53+00:00

fetchf_uristring() was failing to handle error values from fetch_setting(), resulting in its attempting to allocate extremely large temporary buffers on the stack (and so overrunning the stack and locking up the machine). Problem reported by Shao Miller .

[settings] Avoid duplicate settings block names

2009-01-31T07:32:20+00:00

Automatically unregister any settings with the same name (and position within the settings tree) as a newly registered settings block. This functionality is generalised out from dhcp.c.

[settings] Add fetch_string_setting_copy()

2009-01-27T19:13:47+00:00

[settings] Ensure fetch_string_setting() returns a NUL-terminated string

2008-11-07T03:48:29+00:00

This fixes a regression introduced in commit 612f4e7: [settings] Avoid returning uninitialised data on error in fetch_xxx_setting() in which the memset() was moved from fetch_string_setting() to fetch_setting(), in order that it would be useful for non-string setting types. However, this neglects to take into account the fact that fetch_string_setting() shrinks its buffer by one byte (to allow for the NUL) before calling fetch_setting(). Restore the memset() in fetch_string_setting(), so that the terminating NUL is guaranteed to actually be a NUL.

[settings] Add the notion of a "tag magic" to numbered settings

2008-10-30T21:47:14+00:00

Settings can be constructed using a dotted-decimal notation, to allow for access to unnamed settings. The default interpretation is as a DHCP option number (with encapsulated options represented as ".". In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to interpret the dotted-decimal notation as referring to non-DHCP options. In this case, it becomes necessary for these contexts to ignore standard DHCP options, otherwise we end up trying to, for example, retrieve the boot filename from SMBIOS. Allow settings blocks to specify a "tag magic". When dotted-decimal notation is used to construct a setting, the tag magic value of the originating settings block will be ORed in to the tag number. Store/fetch methods can then check for the magic number before interpreting arbitrarily-numbered settings.

[settings] Avoid returning uninitialised data on error in fetch_xxx_setting()

2008-10-22T21:07:13+00:00

Callers (e.g. usr/autoboot.c) may not check the return values from fetch_xxx_setting(), assuming that in error cases the returned setting value will be "empty" (for some sensible value of "empty"). In particular, if the DHCP server did not specify a next-server address, this would result in gPXE using uninitialised data for the TFTP server IP address.

[settings] Allow for setting fetchers to fail in fetchf_hex()

2008-09-26T02:39:35+00:00

[settings] Add the uristring setting type

2008-09-24T06:22:42+00:00

This allows settings to be expanded in a way that is safe to include within a URI string, such as kernel http://10.0.0.1/boot.php?mf=${manufacturer:uristring} where the ${manufacturer} setting may contain characters that are not permitted (or have reserved purposes) within a URI. Since whitespace characters will be URI-encoded (e.g. "%20" for a space character), this also works around the problem that spaces within an expanded setting would cause the shell to split command-line arguments incorrectly.

[settings] Avoid overwriting the start of .text in fetch_string_setting()

2008-08-14T02:03:53+00:00

fetch_string_setting() was subtracting one from the length of the to-be-NUL-terminated buffer in order to obtain the length of the unterminated buffer to be passed to fetch_setting(). This works extremely well unless the length of the to-be-NUL-terminated buffer is zero, at which point we end up giving fetch_setting() a buffer of length -1UL, thereby inviting it to overwrite as much memory as it wants...