On Fri, Jan 26, 2018 at 7:28 AM, Igor Stoppa [off-list ref] wrote:

On 25/01/18 17:38, Jerome Glisse wrote:

quoted

On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote:

quoted

On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa [off-list ref] wrote:

[...]

quoted

DMA/physmap access coupled with a knowledge of which virtual mappings
are in the physical space should be enough for an attacker to bypass
the gating mechanism this work imposes. Not trivial, but not
impossible. Since there's no way to prevent that sort of access in
current hardware (especially something like a NIC or GPU working
independently of the CPU altogether)

[...]

quoted

I am not saying that this can not happen but that we are trying our best
to avoid it.

How about an opt-in verification, similar to what proposed by Boris
Lukashev?

When reading back the data, one could access the pointer directly and
bypass the verification, or could use a function that explicitly checks
the integrity of the data.

Starting from an unprotected kmalloc allocation, even just turning the
data into R/O is an improvement, but if one can afford the overhead of
performing the verification, why not?

I like the idea of making the verification call optional for consumers
allowing for fast/slow+hard paths depending on their needs.
Cant see any additional vectors for abuse (other than the original
ones effecting out-of-band modification) introduced by having
verify/normal callers, but i've not had enough coffee yet. Any access
races or things like that come to mind for anyone? Shouldn't happen
with a write-once allocation, but again, lacking coffee.

It would still be better if the service was provided by the library,
instead than implemented by individual users, I think.

--
igor

-Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html