On Wed 03 Aug 08:55 PDT 2016, Luis R. Rodriguez wrote: > On Wed, Aug 03, 2016 at 08:57:09AM +0200, Daniel Wagner wrote: > > On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: [..] > > Not sure if I get you here correctly. Is the 'system configurable > > deterministic file' is a knob which controlled by user space? Or it > > this something you define at compile time? > > I meant at compile time on the kernel. So CONFIG_READ_READY_SENTINEL > or something like this, and it be a string, which if set then when > the kernel read APIs are used, then a new API could be introduced > that would *only* enable reading through once that sentinel has > been detected by the kernel to allowed through reads. Doing this > per mount / target filesystem is rather cumbersome given possible > overlaps in mounts and also pivot_root() being possible, so instead > targeting simply the fs/exec.c enum kernel_read_file_id would seem > more efficient and clean but we would need a decided upon set of > paths per enum kernel_read_file_id as base (or just one path per > enum kernel_read_file_id). For number of paths I mean the number > of target directories to look for the sentinel per enum kernel_read_file_id, > so for instance for READING_FIRMWARE perhaps just deciding on /lib/firmware/ > would suffice, but if this supported multiple paths another option may be > for the sentinel to also be looked for in /lib/firmware/updates/, > /lib/firmware/" UTS_RELEASE -- etc. It would *stop* after finding one > sentinel on any of these paths. > > If a system has has CONFIG_READ_READY_SENTINEL it would mean an agreed upon > system configuration has been decided so that at any point in time reads > against READING_FIRMWARE using a new kernel_read_file_from_path_sentinel() > (or something like it) would only allow the read to go through once > the sentinel has been found for READING_FIRMWARE on the agreed upon > paths. > > The benefit of the sentintel approach is it avoids complexities with > pivot_root(), and makes the deterministic aspect of the target left > only to a system-configuration enabled target path / file. > This sounds reasonable, it could be configured to wait for a certain static file or userspace could generate this file once it reaches some checkpoint. Just to provide some additional input to "will rootfs mounted be enough of a sentinel". In an Android device you have a initramfs that will read an fstab file and mount /system that holds most firmware, for some platforms additional firmware will come from a third partition (in the Qualcomm case mounted in /persist by the same mechanism). With the sentinel approach one could configure the system either point it at a file in the last file system to be mounted or have init generate a file once its done with this; or in the generic configuration just wait for /lib/firmware to show up. I like this approach. > This is just an idea. I'd like some FS folks to review. > Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
