Like the discussion, I'll add a flag to select discard and/or zero out.
We need to send the discard first between those, because we'll send
the discard to a zero-ed new block, if we zero out first.
2020년 6월 9일 (화) 오전 10:16, Chao Yu 님이 작성:
>
> On 2020/6/8 21:07, Jaegeuk Kim wrote:
> > On 06/08,
On 2020/6/8 21:07, Jaegeuk Kim wrote:
> On 06/08, Chao Yu wrote:
>> On 2020/6/8 15:19, Daeho Jeong wrote:
>>> Yes, I agree with you about each vendor has different implementation on
>>> discard.
>>> So, we might be gonna use the combination of zeroing and send discards
>>> for a more
>>> secure
On 2020/6/8 20:44, Daeho Jeong wrote:
Since spec didn't restrict how vendor implement the erase interface, so
in order to enhance performance of discard interface, vendor could
implement
it as an async one, which may not zero mapping entry(L1 table), instead, it
could set
On 06/08, Chao Yu wrote:
> On 2020/6/8 15:19, Daeho Jeong wrote:
> > Yes, I agree with you about each vendor has different implementation on
> > discard.
> > So, we might be gonna use the combination of zeroing and send discards
> > for a more
> > secure solution. :)
>
> IIRC, current solution
> >> Since spec didn't restrict how vendor implement the erase interface, so
> >> in order to enhance performance of discard interface, vendor could
> >> implement
> >> it as an async one, which may not zero mapping entry(L1 table), instead, it
> >> could set related bitmap to invalid that
On 2020/6/8 15:19, Daeho Jeong wrote:
> Yes, I agree with you about each vendor has different implementation on
> discard.
> So, we might be gonna use the combination of zeroing and send discards
> for a more
> secure solution. :)
IIRC, current solution is:
- pin file
- get all block addresses
Yes, I agree with you about each vendor has different implementation on discard.
So, we might be gonna use the combination of zeroing and send discards
for a more
secure solution. :)
I think we still need a discard interface to unmap from the mapping
table of the storage device side.
Thanks,
On 2020/6/8 11:36, Daeho Jeong wrote:
> Yes, this is for security key destruction.
>
> AFAIK, discard will unmap the data block and, after done it,
> we can read either zero data or garbage data from that block depending
> on eMMC/UFS.
Since spec didn't restrict how vendor implement the erase
Yes, this is for security key destruction.
AFAIK, discard will unmap the data block and, after done it,
we can read either zero data or garbage data from that block depending
on eMMC/UFS.
In a view point of read data, it might be the same with zeroing the data block.
However, since we can even
On 2020/6/5 12:27, Daeho Jeong wrote:
> From: Daeho Jeong
>
> Added a new ioctl to send discard commands to whole data area of
> a regular file for security reason.
I guess this interface is introduced for security key destruction, if I'm
right, however, IIRC, discard(erase) semantics in
10 matches
Mail list logo
