linux-kernel - Re: RFC: A reduced Linux network stack for small systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 May 2014 14:05:30 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: A reduced Linux network stack for small systems

On Tue, May 6, 2014 at 1:00 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> not quite. I'm saying: no extra optimizations, no GCC changes.
>> Compile kernel as-is. Most functions have a stub for mcount() already.
>> Use it to track whether kernel function was called or not.
>> Collect this data in userspace (as perf already does), add few
>> more functions that had 'notrace' attribute on them, and feed this into
>> special linker that unpacks existing vmlinux, throws away cold functions,
>> relocates the rest and here you have tiny vmlinux without recompilation.
>
> That's very difficult for networking code. How would you know you
> exercised all the corner cases in the TCP stack? And you wouldn't
> want a remotely exploitable system because some important error
> handler is missing.

I think removing functions by linker will get you the same level of bugs
then stubbing functions out by kconfig.
One doesn't have to use profile feedback to remove them.
Either linker or config approach seems pretty much equivalent to me.
In case of config, a lot of patches need to be reviewed and maintained.
In case of linker the embedded setup can pick and choose without burdening
mainline. If it crashes, it will be clear that it crashed due to call to removed
function. Iteratively you'll get a setup that works for this
particular application.
Both approaches are full of potential crashes, undoing removal is much
easier with linker. Best solution is to add memory and don't mess with .text.

> I agree it may work for some other subsystems.
>
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/