Hi.
I have a question about 'vdso_install'.
In my understanding, vdso is embedded in the kernel.
In addition, you can run 'make vdso_install'
to install an unstripped version of vdso.
(Mainly, debugging purpose?)
By default, 'make vdso_install' will install it to
/lib/modules/$(uname -r)/vdso/.
Since that directly is owned by root,
'make vdso_install' could potentially be
executed by root, isn't it?
Currently, 'vdso_install' depends on vdso,
so it may cause recompilation of objects
in the source tree.
This violates the basic rule:
"Installation targets must not modify the source tree".
We often miss this point. For example, see
commit 19514fc665ffbce624785f76ee7ad0ea6378a527
If this is a problem, I will fix Makefiles to
make 'vdso_install' not depend on vdso
Thanks.
--
Best Regards
Masahiro Yamada
On Thu, Apr 18, 2019 at 1:08 AM Masahiro Yamada
<[email protected]> wrote:
>
> Hi.
>
> I have a question about 'vdso_install'.
>
>
> In my understanding, vdso is embedded in the kernel.
> In addition, you can run 'make vdso_install'
> to install an unstripped version of vdso.
> (Mainly, debugging purpose?)
>
> By default, 'make vdso_install' will install it to
> /lib/modules/$(uname -r)/vdso/.
>
>
> Since that directly is owned by root,
> 'make vdso_install' could potentially be
> executed by root, isn't it?
>
>
> Currently, 'vdso_install' depends on vdso,
> so it may cause recompilation of objects
> in the source tree.
Hmm. I suppose an alternative would be for vdso_install to fail if
the vdso isn't built?
What's the ideal outcome here?
On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski <[email protected]> wrote:
>
> Hmm. I suppose an alternative would be for vdso_install to fail if
> the vdso isn't built?
I absolutely abhor even the concept of building the kernel as root,
and I think it should be actively disallowed. Our build system is
good, but it's good as in "clever and complex" rather than necessarily
good as in "very secure".
So anybody who builds the kernel as root is doing something seriously
wrong, in my opinion.
That's partly exactly _because_ we have a lot of magical and very
powerful build rules, and complicated implicit things going on.
For example, our dependencies aren't even about just the files in the
kernel repository itself, we have clever things like "if the compiler
has been updated and features or version changes, we'll automatically
rebuild, because it's part of our clever build system checks".
But that is also part of the reason why I absolutely do *not* want any
root-building to happen, because our build setup is simply way too
clever.
If root builds stuff, you'll end up with root-owned generated
subdirectories or various config files etc, and even if you don't have
security issues, it can complicate the build later as a regular user.
I've had the build occasionally fail in odd ways, because some
root-owned file was now no longer removable (usually it's the
auto-generated header files in the directory, and the root-generated
and owned directory is now not writable by the developer any more).
And every time it happens, I shudder.
So all of that simply boils down to "root should not be running those
complex rules for our config and dependency magic".
At the same time, "make install" obviously needs to be done as root.
All of which is why I opine that "make install" should never build
anything at all, it should purely be used as a "install previously
built files".
So yes, I'd much prefer just failing over trying to build as root (or
even trying to figure out dependencies as root).
> What's the ideal outcome here?
I'd basically like the rule for "make install" to be that it never
ever generates a single file in the build tree, so that there are
never any root-owned (or root-overwritten) files there.
So "make install" should even avoid all dependency checking, for the
simple reason that if you happen to do a system update between "make"
and "make install", our smart dependencies should never say "oh, the
compiler version has changed, so now I'll rebuild everything as root
just because 'make install'".
So I think the ideal outcome is just "fail if you can't find the files
to install".
Linus
> On Apr 23, 2019, at 4:38 PM, Linus Torvalds <[email protected]> wrote:
>
>> On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski <[email protected]> wrote:
>>
>> Hmm. I suppose an alternative would be for vdso_install to fail if
>> the vdso isn't built?
>
> I absolutely abhor even the concept of building the kernel as root,
> and I think it should be actively disallowed. Our build system is
> good, but it's good as in "clever and complex" rather than necessarily
> good as in "very secure".
>
> So anybody who builds the kernel as root is doing something seriously
> wrong, in my opinion.
>
> That's partly exactly _because_ we have a lot of magical and very
> powerful build rules, and complicated implicit things going on.
>
> For example, our dependencies aren't even about just the files in the
> kernel repository itself, we have clever things like "if the compiler
> has been updated and features or version changes, we'll automatically
> rebuild, because it's part of our clever build system checks".
>
> But that is also part of the reason why I absolutely do *not* want any
> root-building to happen, because our build setup is simply way too
> clever.
>
> If root builds stuff, you'll end up with root-owned generated
> subdirectories or various config files etc, and even if you don't have
> security issues, it can complicate the build later as a regular user.
>
> I've had the build occasionally fail in odd ways, because some
> root-owned file was now no longer removable (usually it's the
> auto-generated header files in the directory, and the root-generated
> and owned directory is now not writable by the developer any more).
> And every time it happens, I shudder.
>
> So all of that simply boils down to "root should not be running those
> complex rules for our config and dependency magic".
>
> At the same time, "make install" obviously needs to be done as root.
>
> All of which is why I opine that "make install" should never build
> anything at all, it should purely be used as a "install previously
> built files".
>
> So yes, I'd much prefer just failing over trying to build as root (or
> even trying to figure out dependencies as root).
>
>> What's the ideal outcome here?
>
> I'd basically like the rule for "make install" to be that it never
> ever generates a single file in the build tree, so that there are
> never any root-owned (or root-overwritten) files there.
>
> So "make install" should even avoid all dependency checking, for the
> simple reason that if you happen to do a system update between "make"
> and "make install", our smart dependencies should never say "oh, the
> compiler version has changed, so now I'll rebuild everything as root
> just because 'make install'".
>
> So I think the ideal outcome is just "fail if you can't find the files
> to install".
>
>
To clarify, this is “fail if you can’t find the files to install, but don’t even try to check whether those files are up to date”, right?
On Wed, Apr 24, 2019 at 8:40 AM Linus Torvalds
<[email protected]> wrote:
>
> On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski <[email protected]> wrote:
> >
> > Hmm. I suppose an alternative would be for vdso_install to fail if
> > the vdso isn't built?
>
> I absolutely abhor even the concept of building the kernel as root,
> and I think it should be actively disallowed. Our build system is
> good, but it's good as in "clever and complex" rather than necessarily
> good as in "very secure".
>
> So anybody who builds the kernel as root is doing something seriously
> wrong, in my opinion.
>
> That's partly exactly _because_ we have a lot of magical and very
> powerful build rules, and complicated implicit things going on.
>
> For example, our dependencies aren't even about just the files in the
> kernel repository itself, we have clever things like "if the compiler
> has been updated and features or version changes, we'll automatically
> rebuild, because it's part of our clever build system checks".
>
> But that is also part of the reason why I absolutely do *not* want any
> root-building to happen, because our build setup is simply way too
> clever.
>
> If root builds stuff, you'll end up with root-owned generated
> subdirectories or various config files etc, and even if you don't have
> security issues, it can complicate the build later as a regular user.
>
> I've had the build occasionally fail in odd ways, because some
> root-owned file was now no longer removable (usually it's the
> auto-generated header files in the directory, and the root-generated
> and owned directory is now not writable by the developer any more).
> And every time it happens, I shudder.
>
> So all of that simply boils down to "root should not be running those
> complex rules for our config and dependency magic".
>
> At the same time, "make install" obviously needs to be done as root.
>
> All of which is why I opine that "make install" should never build
> anything at all, it should purely be used as a "install previously
> built files".
>
> So yes, I'd much prefer just failing over trying to build as root (or
> even trying to figure out dependencies as root).
>
> > What's the ideal outcome here?
>
> I'd basically like the rule for "make install" to be that it never
> ever generates a single file in the build tree, so that there are
> never any root-owned (or root-overwritten) files there.
>
> So "make install" should even avoid all dependency checking, for the
> simple reason that if you happen to do a system update between "make"
> and "make install", our smart dependencies should never say "oh, the
> compiler version has changed, so now I'll rebuild everything as root
> just because 'make install'".
>
> So I think the ideal outcome is just "fail if you can't find the files
> to install".
>
> Linus
I assume this is ACK to change vdso Makefiles.
I will send patches.
Thanks.
--
Best Regards
Masahiro Yamada
On Tue, Apr 23, 2019 at 4:57 PM Andy Lutomirski <[email protected]> wrote:
>
> To clarify, this is “fail if you can’t find the files to install, but don’t even try to check whether those files are up to date”, right?
Ack. Exactly because the whole "check whether the files are
up-to-date" is generally part of the very complex dance of doing all
the version stuff etc.
Linus
On Tue, Apr 23, 2019 at 04:38:35PM -0700, Linus Torvalds wrote:
> So anybody who builds the kernel as root is doing something seriously
> wrong, in my opinion.
Some of my test boxes don't have a user account... if they fall over,
I'll just re-image them.
So I've been doing it wrong?