* PaX Team <pagee...@freemail.hu> wrote:
> On 26 Nov 2015 at 9:54, Ingo Molnar wrote:
>
> > * PaX Team <pagee...@freemail.hu> wrote:
> >
> > > actually the kernel could silently recover from this given how the page
> > > fault
> > > handler could easily determine that the fault address fell into the
> > > data..read_only section and just silently undo the read-only property,
> > > log the
> > > event to dmesg and retry the faulting access.
> >
> > So a safer method would be to decode the faulting instruction, to skip it
> > by
> > fixing up the return RIP and to log the event. It would be mostly
> > equivalent
> > to trying to write to ROM (which get ignored as well), so it's a
> > recoverable
> > (and debuggable) event.
>
> if by skipping you mean ignoring the write attempt then it's not a good idea
> as
> it has a good chance to cause unexpected behaviour down the line.
>
> e.g., imagine that the write was to a function pointer (even an entire ops
> structure) or a boolean that controls some important feature for after-init
> code. ignoring/dropping such writes could cause all kinds of logic bugs (if
> not
> worse).
Well, the typical case is that it's a logic bug to _do_ the write: the
structure
was marked readonly for a reason but some init code re-runs during suspend or
so.
But yes, logic bugs might trigger - but that is true in the opposite case as
well,
if we do the write despite it being marked readonly:
> my somewhat related war story is that i once tried to constify machine_ops
> (both
> the struct and the variable of the same name) directly and just forced the
> writes in kvm/xen/etc via type casts. now i knew it was all undefined
> behaviour
> but i didn't expect gcc to take advantage of it but it did (const propagated
> the
> *initial* fptr values into the indirect calls by turning them into direct
> calls)
> and which in turn prevented proper reboots for guests (an event which
> obviously
> happens much later after init/boot to the great puzzlement of end users and
> myself).
>
> misusing __read_only and ignoring write attempts would effectively produce
> the
> same misbehaviour as above so i strongly advise against it.
No, the difference to the GCC related aliasing bug is that with my technique
the
kernel would immediately produce a very visible kernel warning, which is a very
clear sign that is wrong - and with a very clear backtrace in the warning that
points right to the problematic code - which signature shows us (and users)
what
is wrong.
So your example is not comparable at all.
Plus the truly paranoid might panic/halt the system on such warnings, so for
highly secure systems there's a way to not even allow the possibility of logic
bugs. (at the cost of stopping the system when a bug triggers.)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
