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, Cha
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 so
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 is
> >> 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 mapping
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 o
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,
2020
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 int
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 unm
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 eMMC/UF
10 matches
Mail list logo