Roland McGrath wrote:
The earlier patches in this series change the linker script to place it
appropriately and set the phdr. It's allocated when its input sections are
allocated. Current builds I've seen don't have any input note sections at
all. My motivation is for the ld --build-id support
> Is .notes an allocated section? I didn't think it necessarily appeared
> in any of the PT_LOAD segments, because the linux/elfnote.h macros don't
> necessarily set "a" on the section.
The earlier patches in this series change the linker script to place it
appropriately and set the phdr. It's
> I'm curios to know what happens if nobody defines __start_notes and
> __end_notes. We'll use the extern-attribute-weak thing, but those two
> locations won't even get instantiated in vmlinux, I think.
>
> And the code relies upon the difference between two non-existent
> attribute-weak location
Roland McGrath wrote:
This patch adds the /sys/kernel/notes magic file. Reading this delivers
the contents of the kernel's .notes section. This lets userland easily
glean any detailed information about the running kernel's build that was
stored there at compile time.
Is .notes an allocated
On Wed, 11 Jul 2007 12:04:34 -0700 (PDT)
Roland McGrath <[EMAIL PROTECTED]> wrote:
> +/*
> + * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
> + */
> +extern const char __start_notes __attribute__((weak));
> +extern const char __stop_notes __attribute__((weak));
> +#de
On Wed, 11 Jul 2007, Roland McGrath wrote:
>
> > If it's basically just a set of hashes, I won't worry.
>
> It's just one hash. (Each .ko has one too, but I didn't bother with the
> /sys/module/name/notes hack because it was too much trouble.)
Ok, then I withdraw any objection. The only way t
> Ok, that doesn't sound bad. Is the "note" something global for the whole
> thing, or are there per-object file notes that you can parse (ie can you
> figure out which modules are linked in some way?)
Usually there is one per final link, so one in vmlinux and one in each .ko.
There is nothing y
On Wed, 11 Jul 2007, Roland McGrath wrote:
>
> It will give them at least as reliable an identification of the kernel
> binary as the "uname -rv" info if they have access to a set of candidate
> known binaries to select from.
Ok, that doesn't sound bad. Is the "note" something global for the wh
> Yeah, we've made that mistake before, and I'm not saying we are perfect
> here, but if we make this world-readable, I think it needs to guarantee it
> doesn't really give any rootkit people any new information.
It will give them at least as reliable an identification of the kernel
binary as th
On Wed, 11 Jul 2007, Roland McGrath wrote:
>
> It hadn't really occurred to me that the kernel binary would be
> deliberately hidden from the user.
We don't want to have things like config info, or really preferably
anything that can be used to generate kernel addresses.
Yeah, we've made that
[I'd meant to send that from [EMAIL PROTECTED], so please correct any
followups.]
> Umm. You seem to make it readable by everybody. That's a mistake, I think.
> I don't know if there is anything security-conscious there, but just on
> general principles, I don't think we really would want normal
On Wed, 11 Jul 2007, Roland McGrath wrote:
>
> This patch adds the /sys/kernel/notes magic file. Reading this delivers
> the contents of the kernel's .notes section. This lets userland easily
> glean any detailed information about the running kernel's build that was
> stored there at compile t
12 matches
Mail list logo
