On Wed, Feb 03, 2016 at 02:13:54PM +0000, Matt Fleming wrote: >On Wed, 03 Feb, at 08:02:47AM, Peter Jones wrote: >> "rm -rf" is bricking some peoples' laptops because of variables being >> used to store non-reinitializable firmware driver data that's required >> to POST the hardware. >> >> These are 100% bugs, and they need to be fixed, but in the mean time it >> shouldn't be easy to *accidentally* brick machines. >> >> We have to have delete working, and picking which variables do and don't >> work for deletion is quite intractable, so instead make everything >> immutable by default (except for a whitelist), and make tools that >> aren't quite so broad-spectrum unset the immutable flag. >> >> v2: adds Timeout to our whitelist. >> >> Signed-off-by: Peter Jones <pjones@xxxxxxxxxx> >> --- >> drivers/firmware/efi/vars.c | 83 +++++++++++++++++++++++++++++++++------------ >> fs/efivarfs/file.c | 69 +++++++++++++++++++++++++++++++++++++ >> fs/efivarfs/inode.c | 32 +++++++++++------ >> fs/efivarfs/internal.h | 3 +- >> fs/efivarfs/super.c | 9 +++-- >> include/linux/efi.h | 2 ++ >> 6 files changed, 163 insertions(+), 35 deletions(-) > >I see no mention of the benefit of using the immutable flag versus >making all protected files read-only. > >Is it not possible to just make everything that needs protecting 444? >That way users can use standard tools if they really, really want to >delete/write to a variable. It has the added benefit of protecting >users from trashing variables that are important for POST too (as >opposed to deleting them altogether). Just making them read-only won't stop people trashing things as root. They're already owned by root anyway aren't they?? Although if we're at the stage of doing things this wat then is there much to be gained by having a filesystem interface in the first place? -- Steve McIntyre, Cambridge, UK. steve@xxxxxxxxxx < liw> everything I know about UK hotels I learned from "Fawlty Towers" -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
