On Tue, 26 Apr 2011, Chris Ball wrote:
> Hi John,
>
> On Tue, Apr 26 2011, John Calixto wrote:
> > Arnd - Thanks a lot for the review and your help getting the
> > implementation right!
> >
> > Chris - What do you think? How should I proceed here?
>
> I t
On Tue, 26 Apr 2011, Arnd Bergmann wrote:
> On Friday 22 April 2011, John Calixto wrote:
> > Allows appropriately-privileged applications to send CMD (normal) and
> > ACMD (application-specific; preceded with CMD55) commands to
> > cards/devices on the mmc bus. This is
On Thu, 21 Apr 2011, John Calixto wrote:
> +static struct mmc_blk_ioc_data *mmc_blk_ioctl_copy_from_user(
> + struct mmc_ioc_cmd __user *user)
> +{
> + struct mmc_blk_ioc_data *idata;
> + int err;
> +
> + idata = kzalloc(sizeof(*idata), GFP_KERNEL
passthrough, it is very possible
to render the card/device unusable. Applications that use this ioctl
must have CAP_SYS_RAWIO.
Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652
SoC, TI OMAP3621 SoC, TI OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm
MSM7200A SoC.
Signed-off-by: John
change history for this patch:
- v7
- simplify 32-bit/64-bit buffer pointer portability
- add pad member to struct mmc_ioc_cmd so its size is the same
when built for either 32-bit or 64-bit.
- register ``0xB3`` in Documentation/ioctl/ioctl-number.txt
- v6
- refix 32+64 compa
On Wed, 20 Apr 2011, Michał Mirosław wrote:
> >> I'm okay with the anon union + ``compat_ptr(*(u32 *))`` part of your
> >> solution. If everyone else thinks it is reasonable, I'll submit a v7
> >> with it.
> > No need for a union or a ptr_size member in the struct. Just use
> > a single __u64 and
Hi Arnd,
On Wed, 20 Apr 2011, Arnd Bergmann wrote:
>
> No need for a union or a ptr_size member in the struct. Just use
> a single __u64 and let the user cast the pointer to that. This
> will work on all architectures.
>
> > However, I still think it should be implemented in compat_ioctl()
> >
Hi Michał,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
> Hmm. This might be even better:
>
> static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
> unsigned int cmd, unsigned long arg)
> {
> struct mmc_ioc_cmd blk;
>
> if (cmd != MMC_IOC_CMD)
> return -EINVAL;
>
> copy_fr
Hi Michal,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
>
> So... again... What's the problem with anonymous union of pointer and u64?
>
As Arnd pointed out, this would not work for big endian machines.
John
Chris,
Have you had the chance to look at v6 of this patch? If so, what do you
think?
John
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 18 Apr 2011, Arnd Bergmann wrote:
> In v6, it seems you have implemented the full CMD passthrough, if I
> read it correctly. Is there anything still missing?
>
Hi Arnd,
As far as I have tested, the v6 patch does indeed have full CMD
passthrough.
John
--
To unsubscribe from this list: se
On Mon, 18 Apr 2011, Arnd Bergmann wrote:
> On Wednesday 13 April 2011, John Calixto wrote:
> > Gah! OK, so much for the v5 I just sent then. What do you think about
> > the compat_ioctl that I sent in v2? It means having the extra 32-bit
> > compat structure, but at
passthrough, it is very possible
to render the card/device unusable. Applications that use this ioctl
must have CAP_SYS_RAWIO.
Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652
SoC, TI OMAP3621 SoC, TI OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm
MSM7200A SoC.
Signed-off-by: John
The changes in this version are mostly to address Arnd's comments on v4.
Arnd, I added a flag to allow the caller to select between normal CMDs
and ACMDs. This really makes it a generic passthrough. However, I only
tested a few commands to see that passthrough was working. I did not
try any adv
On Wed, 13 Apr 2011, Andrei Warkentin wrote:
> mmc_cmd_app did not zero out mmc_command on stack.
>
> Signed-off-by: Andrei Warkentin
> ---
> drivers/mmc/core/sd_ops.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd
Hi Arnd,
On Wed, 13 Apr 2011, Arnd Bergmann wrote:
> On Monday 11 April 2011, John Calixto wrote:
> > Sending ACMDs from userspace is useful for such things as:
> >
> > - The security application of an SD card (SD Specification, Part 3,
> > Security)
> &
Please ignore v5. The fix for the compiler warning is not appropriate
for all endians/archs.
John
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 13 Apr 2011, Arnd Bergmann wrote:
> On Tuesday 12 April 2011, Michał Mirosław wrote:
> > > + unsigned int cmd_timeout_ms;
> > > + __u64 data_ptr; /* DAT buffer */
> >
> > This will be more natural if you have an anonymous union here:
> > union {
> > __u64 data_ptr_
> > void
SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
Reviewed-by: Andrei Warkentin
---
drivers/mmc/card/block.c | 196 +
drivers/mmc/core/sd_ops.c |3 +-
include/linux/Kbuild |1 +
include/linux/mmc/Kbuild |1 +
include/linux
A small fix for a compiler warning. Thanks to Michał Mirosław for
suggesting the solution!
Patch history below:
- v5
- fix 32-bit compiler warning about the 32+64 compat pointer
- v4
- replace postsleep udelay() with usleep_range()
- add cmd_timeout_ms field for R1B commands
- v3
On Tue, 12 Apr 2011, Michał Mirosław wrote:
> 2011/4/11 John Calixto :
> [...]
> > --- /dev/null
> > +++ b/include/linux/mmc/ioctl.h
> > @@ -0,0 +1,32 @@
> > +#ifndef _MMC_IOCTL_H
> > +#define _MMC_IOCTL_H
> > +struct mmc_ioc_cmd {
> > + /*
On Mon, 11 Apr 2011, Chris Ball wrote:
> This adds two gcc warnings here (compiling for ARM):
>
> CC drivers/mmc/card/block.o
> drivers/mmc/card/block.c: In function ‘mmc_blk_ioctl_copy_from_user’:
> drivers/mmc/card/block.c:199:33: warning: cast to pointer from integer of
> different size
SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
Reviewed-by: Andrei Warkentin
---
drivers/mmc/card/block.c | 196 +
drivers/mmc/core/sd_ops.c |3 +-
include/linux/Kbuild |1 +
include/linux/mmc/Kbuild |1 +
include/linux
Since this patch has gone through multiple revisions now, I thought I'd
list the changes in each revision:
- v4
- replace postsleep udelay() with usleep_range()
- add cmd_timeout_ms field for R1B commands
- v3
- copy data from userspace before claiming host
- break out copy from u
Hi Andrei,
On Tue, 5 Apr 2011, Andrei Warkentin wrote:
> diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
> index 07f27af..a7d7da7 100644
> --- a/include/linux/mmc/core.h
> +++ b/include/linux/mmc/core.h
> @@ -92,7 +92,7 @@ struct mmc_command {
> * actively failing r
On Fri, 8 Apr 2011, Andrei Warkentin wrote:
>
> I'm not sure what the etiquette for this list is, but you can a
> Reviewed-by: Andrei Warkentin
>
> ...if that's alright with the maintainers.
>
Will do - Thanks for taking the time Andrei!
John
--
To unsubscribe from this list: send the line "u
Hi Andrei,
On Fri, 8 Apr 2011, Andrei Warkentin wrote:
> Is the timeout fixed or variable (I've seen all timeouts in the
> simplified ASSD to be specified in units of 250ms in fields of
> ASSD-PR)? Are you using this force_timeout_ns for DAT-transfer
> commands also, or just for R1B commands?
Act
Hi Andrei,
On Fri, 8 Apr 2011, Andrei Warkentin wrote:
> Hi John,
>
> On Thu, Apr 7, 2011 at 8:18 PM, John Calixto
> wrote:
> > + /* data.flags must already be set before doing this. */
> > + mmc_set_data_timeout(&data, card);
> > + /* A
SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
---
drivers/mmc/card/block.c | 184 +
drivers/mmc/core/sd_ops.c |3 +-
include/linux/Kbuild |1 +
include/linux/mmc/Kbuild |1 +
include/linux/mmc/core.h |1 +
include
On Wed, 6 Apr 2011, Michał Mirosław wrote:
> 2011/4/6 John Calixto :
> > On Tue, 5 Apr 2011, Andrei Warkentin wrote:
> >> Could you check the SD behavior for undefined ACMDs? If I do ACMD25,
> >> and ACMD25 is not defined, will it be executed as CMD25? This is the
On Wed, 6 Apr 2011, Michał Mirosław wrote:
> 2011/4/5 John Calixto :
> > + /*
> > + * Only allow ACMDs on the whole block device, not on partitions.
> > This
> > + * prevents overspray between sibling partitions.
> > + */
> >
On Tue, 5 Apr 2011, Andrei Warkentin wrote:
> Could you check the SD behavior for undefined ACMDs? If I do ACMD25,
> and ACMD25 is not defined, will it be executed as CMD25? This is the
> MMC behavior as I have mentioned.
The SD spec has a similar paragraph about unspecified ACMD opcodes -
they sh
On Tue, 5 Apr 2011, Andrei Warkentin wrote:
> Let me clarify, this is what the MMC spec says:
>
>
> The only effect of the APP_CMD is that if the command index of
> the, immediately, following command
> has an ACMD overloading, the non standard version will used. If,
> as an example,
On Tue, 5 Apr 2011, Andrei Warkentin wrote:
> On Tue, Apr 5, 2011 at 4:59 PM, John Calixto
> wrote:
> > Some ACMDs might actually damage the card. This check ensures the
> > caller has CAP_SYS_ADMIN before allowing such an activity.
> >
> > Signed-off-by: John Cal
On Tue, 5 Apr 2011, Alan Cox wrote:
> CAP_SYS_RAWIO for "can damage stuff".
>
Will do. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Some ACMDs might actually damage the card. This check ensures the
caller has CAP_SYS_ADMIN before allowing such an activity.
Signed-off-by: John Calixto
---
drivers/mmc/card/block.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers
SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
---
drivers/mmc/card/block.c | 191 +
drivers/mmc/core/sd_ops.c |3 +-
include/linux/mmc/core.h |1 +
include/linux/mmc/sd.h| 16
4 files changed, 210 insertions(+), 1
On Wed, 23 Mar 2011, Michał Mirosław wrote:
> When you grant write access to a device to some user, you should
> expect that it is all you are granting. There shouldn't be any hidden
> doors that, for example, if underlying device is SD card then you can
> destroy it by this ioctl(). Not counting w
On Tue, 22 Mar 2011, Michał Mirosław wrote:
> >> In this case, a process having access to one partition can disrupt
> >> other partitions on the same card even if it has no access to them in
> >> any other way.
> > This is true, but I can already wreak havoc on partitions for any block
> > device b
On Sat, 19 Mar 2011, Michał Mirosław wrote:
> W dniu 18 marca 2011 20:26 użytkownik Arnd Bergmann napisał:
> > On Friday 18 March 2011 18:56:53 Michał Mirosław wrote:
> >> If that's going to be used by possibly unprivileged userspace process,
> >> then this passthrough should filter and validate a
On Mon, 21 Mar 2011, Andrei Warkentin wrote:
> 2011/3/21 Arnd Bergmann :
> > On Sunday 20 March 2011, Michał Mirosław wrote:
> >> 2011/3/20 John Calixto :
> >> > On Sat, 19 Mar 2011, Arnd Bergmann wrote:
> >> [...]
> >> >> > I expect f
On Sat, 19 Mar 2011, Arnd Bergmann wrote:
> Many of the SD specifications have redacted versions that allow
> us to write OS drivers. For instance there is
> http://www.sdcard.org/developers//tech/sdcard/pls/simplified_specs/Part_A1_ASSD_Extension_Simplified_Specification_Ver2.00_Final_100518.pdf
>
Hello Arnd,
I need some clarification on the last bit of your initial feedback below:
On Thu, 17 Mar 2011, Arnd Bergmann wrote:
> On Thursday 17 March 2011 19:28:55 John Calixto wrote:
> > diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
> > index 797cdb5.
On Fri, 18 Mar 2011, Arnd Bergmann wrote:
> On Friday 18 March 2011 18:32:41 John Calixto wrote:
> > I started down that route, but part of the problem with putting any more
> > than a simple passthrough in kernel space is that the CPRM algorithms
> > live in the next highes
Hello Arnd,
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, March 17, 2011 2:56 PM
> To: John Calixto
> Cc: linux-mmc@vger.kernel.org; c...@laptop.org
> Subject: Re: [PATCH resend] mmc: Added ioctl to let userspace apps send ACMDs
access this
security feature.
Tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC, TI OMAP3621 SoC, TI
OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
---
(I'm resending because I forgot to cc the maintainer - sorry!)
drivers/mmc/card/block.c |
access this
security feature.
Tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC, TI OMAP3621 SoC, TI
OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
Signed-off-by: John Calixto
---
drivers/mmc/card/block.c | 149 +
drivers/mmc/core
47 matches
Mail list logo
