On Fri, Apr 03, 2020 at 04:57:51PM -0700, Kees Cook wrote: > On Thu, Apr 02, 2020 at 08:59:32PM +0000, Luis Chamberlain wrote: > > We modify the copied bootparams to allow new sysctls to map to old boot params? > > This strdup is so that the > command line can have '\0's injected while it steps through the args > (and for doing the . and / replacement). Please ignore the const feedback then. > > This is the least cumbersome solution I could think of. Other things > > would require things like using qemu, etc. That seems much more messsy. > > Yes. Doing an internal extension isn't testing the actual code. But it would. > > > This is an external interface (boot params), so > > > I'd rather an external driver handle that testing. We don't have a > > > common method to do that with the kernel, though. > > > > Right... which begs the question now -- how do we test this sort of > > stuff? The above would at least get us coverage while we iron something > > more generic out for boot params. > > > > > > That would test both cases with one kernel. > > > > > > > > You could then also add a bogus new sysctl which also expands to a silly > > > > raw boot param to test the wrapper you are providing. That would be the > > > > only new test syctl you would need to add. > > > > > > Sure, that seems reasonable. Supporting externally driven testing makes > > > sense for this. > > > > But again, what exactly? > > I don't think anything is needed for this series. It can be boot tested > manually. Why test it manually when it could be tested automatically with a new kconfig? Luis
