On Fri, 2019-05-03 at 07:52:53 UTC, Andrew Donnellan wrote:
> Currently the OPAL symbol map is globally readable, which seems bad as it
> contains physical addresses.
>
> Restrict it to root.
>
> Suggested-by: Michael Ellerman
> Cc: Jordan Niethe
> Cc: Stewart Smith
> Fixes: c8742f85125d
Andrew Donnellan writes:
> On 3/5/19 5:52 pm, Andrew Donnellan wrote:
>> Currently the OPAL symbol map is globally readable, which seems bad as it
>> contains physical addresses.
>>
>> Restrict it to root.
>>
>> Suggested-by: Michael Ellerman
>> Cc: Jordan Niethe
>> Cc: Stewart Smith
>>
On 3/5/19 5:52 pm, Andrew Donnellan wrote:
Currently the OPAL symbol map is globally readable, which seems bad as it
contains physical addresses.
Restrict it to root.
Suggested-by: Michael Ellerman
Cc: Jordan Niethe
Cc: Stewart Smith
Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL
On 3/5/19 6:35 pm, Greg KH wrote:
Are we actually racing against userspace in a subsys initcall?
You can be, if you subsys is a module :)
For various reasons, we don't compile core system firmware interfaces
into modules... that could be an interesting exercise. :D
--
Andrew Donnellan
On Fri, May 03, 2019 at 06:27:18PM +1000, Andrew Donnellan wrote:
> On 3/5/19 5:59 pm, Greg KH wrote:>> -static BIN_ATTR_RO(symbol_map, 0);
> > > +static struct bin_attribute symbol_map_attr = {
> > > + .attr = {.name = "symbol_map", .mode = 0400},
> > > + .read = symbol_map_read
> > > +};
> >
>
On 3/5/19 5:59 pm, Greg KH wrote:>> -static BIN_ATTR_RO(symbol_map, 0);
+static struct bin_attribute symbol_map_attr = {
+ .attr = {.name = "symbol_map", .mode = 0400},
+ .read = symbol_map_read
+};
There's no real need to rename the structure, right? Why not just keep
the
On Fri, May 03, 2019 at 05:52:53PM +1000, Andrew Donnellan wrote:
> Currently the OPAL symbol map is globally readable, which seems bad as it
> contains physical addresses.
>
> Restrict it to root.
>
> Suggested-by: Michael Ellerman
> Cc: Jordan Niethe
> Cc: Stewart Smith
> Fixes:
